…inside of the gatekeeper configuration for managing token validation with FIWARE Wilma PEP Poxy, this fields allow to define the PEP proxy host and port to establish the connection. The caching option was changed to false because the token validation option doesn't allow caching yet.

Also, the error messages defined in the api settings were changed for including token as other validation method.

…the word "token" in the url and the header "X-Auth-Token" in the requests made to the platform. With this change is possible to manage and differentiate if the user made a request using an API_Key or OAuth Token

…s allowed to pass the token are by param and header. The variable api_key was changed by a key, value table, this table has two values, fist the key_value that stores the value of the api_key or the token, and the second value called key_type which stores the type of key provided by the user, it can take two values token or api_key

All the variables that previously stored the api_key value, was changed to store api_key ["key_value"], that represents exactly the same value using the new api_key table.

…odified to allow and parse a roles tables that have more than one value by rol, for example: if the function receives the roles in this format Roles":[{"name":"rol1","id":"16"}].

With the modification the function checks if the roles value has more than one value and takes only the value for the key "name" ant after that invert the table.

…ng if the token is valid and retrieve the user information. The function takes the PEP Proxy host and port as parameters and sends a request with the header X-Auth-Token and the value of the token provided by the user.

If the token is valid, PEP proxy sends a response with the user information asociated to the token, otherwise, it sends a message indicating the result of the validation process with his status, 404 , 402, etc.

…on, for achieving this, an extra validation through the key_type value of the api_key variable was used. If the key_value is equal to "api_key", the key_value is checked in the Mongo database. In case of the value of key_values is equal to "token", the token is sent to the PEP Proxy for validation, if the token is valid, the user information is returned.

If the user information is retrieved from the database this information is stored in the variables of the platform as usually did. In case that the user information was retrieved using token validation, the variables the Nick_name is assigned to the user_id and the Roles is assigned to the roles of the platform.
Moreover, if the user information coming from of the token validation with PEP Proxy doesn't have the value of "email", this field is stored in the platform using the Nick_name value, this value is needed for displaying, the user associated with each request in the Analytics option of the web app . The rest of the changes are related to the reassignment of the api_key variable using api_key ["key_value"]

New feature for OAuth2 Token Validation using Fiware Wilma PEP-Proxy, v0.1 OAuth2 authentication with FIWARE Pep Proxy only, next version need to allow OAuth2 token validation with any authentication service provider

…P-Proxy"

Revert "New feature for OAuth2 Token Validation using Fiware Wilma PEP-Proxy"

…inside of the gatekeeper configuration for managing token validation with externals Identity Providers (Fiware, Google, Github, Facebook).

 The caching option was changed to false because the token validation option doesn't allow caching yet.

Also, the error messages defined in the api settings were changed for including token as other validation method.

… the word "token" in the url and the header "X-Auth-Token" in the requests made to the platform. With this change is possible to manage and differentiate if the user made a request using an API_Key or OAuth2 Token

…modified to allow and parse a roles tables that have more than one value by rol, for example: if the function receives the roles in this format Roles":[{"name":"rol1","id":"16"}].

With the modification the function checks if the roles value has more than one value and takes only the value for the key "name" and after that, the function inverts the table.

…, Fiware, Github) for checking if a token is valid and retrieve the user properties. The function takes the token provided by the user and the IdP provider registered in the api-backend for checking if the token is valid making a validation request to the corresponding IdP. If the token is valid, the user information stored in the IdP is retrieved.

…s allowed to pass the token are by param and header. The variable api_key was changed by a key, value table, this table has three elements, first the key_value that stores the value of the api_key or the token, the second value called key_type which stores the type of key provided by the user, it can take two values token or api_key and, Finally, the las element named "idp" has a value that indicates if and which external IdP has the associated the requested api-backend.

All the variables that previously stored the api_key value, was changed to store api_key ["key_value"], that represents exactly the same value using the new api_key table.

…ion, for achieving this, an extra validation through the key_type value of the api_key variable was used. If the key_value is equal to "api_key", the key_value is checked in the Mongo database. In case of the value of key_values is equal to "token", the token is sent to the IdP validation with the corresponding api_key["idp"] value for sending a validation request directly to the IdP associated to the api-backend, if the token is valid, the user information is returned.

If the user information is retrieved from the database this information is stored in the variables of the platform as usually did. In case that the user information was retrieved using token validation and the IdP was Fiware, the variables the id is assigned to the user_id and the Roles is assigned to the roles of the platform.

In case of the other externals IdP, the name and the email of the user are retrieved only.

The rest of the changes are related to the reassignment of the api_key variable using api_key ["key_value"]

…using api_key or token even when an IdP has been associated to that API backend

…ackends by @agordillo

… web interface

…n mode authentication and authorization, for these reasons the request to the IDM are different. For authentication the url needs to include the token and the app-ID and for authorization is needed to include, token, action, resource and app-ID