-
Notifications
You must be signed in to change notification settings - Fork 325
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
External IdP validation feature for API Backends #401
base: main
Are you sure you want to change the base?
Conversation
…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
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
@anmunoz: Hi there! Sorry for the delay in getting back to you. We've been busy with other things, but I'll try to take a look at this in the coming weeks. Thanks for the contribution and getting this started! |
…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
Hi,
And It returns:
def validate_service(self, path):
|
Hi @Urtza2 have you tried with the github repo of apinf (https://github.com/apinf/api-umbrella) forked from api-umbrella?, that repo have a stable release that includes external idp validation. On the other hand this repo have more features for authorization that I think that is not your case of use |
No I have install using these instructions ... And after I make the changes that appear in this issue. |
How can I install API-Umbrella of github repo of apinf (https://github.com/apinf/api-umbrella)?. shell> ./configure and I get some errors like:
I'll try doing the same with NREL repo: What is the correct way to install API-Umbrella of this repo (https://github.com/apinf/api-umbrella) ? Thanks in advance |
I am Andrés Muñoz, from Technical University of Madrid, working with @aalonsog, I have been working on the idea of implementing an external validation service in API-Umbrella in order to verify if a user token is valid or not. For achieving that, I followed the flow showed in the diagram #349 by @aalonsog and the guidelines stated by you in the previous comments.
This new feature allows to the API-umbrella users the possibility of make request to a registered API backend, using an API key or an OAuth2 token. If the user uses a token in the request, this token is verified using an external IdP, once the token is validated the user information is retrieved and redirect to the API backend following the usual workflow. The list of IdP's included in this development are:
Hence, after the inclusion of this feature, the gatekeeper architecture is modified as is showed in the next figure:
This work was made in collaboration with @aalonsog @agordillo and @jsalvachua.
If you have any coment or need more information about it, please let me know.