SlideShare a Scribd company logo

Esquema de pasos de ejecución IdM

•Download as PPTX, PDF•
•
Fernando Lopez Aguilar
Fernando Lopez Aguilar

This document outlines two scenarios for authenticating a web portal using an identity management system (IdM). Scenario 1 describes authenticating when the portal knows the user's credentials, directly sending them to the IdM. Scenario 2 describes authenticating when the portal does not know the credentials, requiring the user to log in via the IdM portal. Both scenarios involve redirecting to the IdM, receiving an access code, using it to request an access token from the IdM, and validating the token to get user information. Reference information is provided at the end.

Related slideshows

Stateless authentication for microservices - Greach 2015
Stateless authentication for microservices - Greach 2015Stateless authentication for microservices - Greach 2015
Stateless authentication for microservices - Greach 2015
 
2016 pycontw web api authentication
2016 pycontw web api authentication 2016 pycontw web api authentication
2016 pycontw web api authentication
 
Stateless authentication with OAuth 2 and JWT - JavaZone 2015
Stateless authentication with OAuth 2 and JWT - JavaZone 2015Stateless authentication with OAuth 2 and JWT - JavaZone 2015
Stateless authentication with OAuth 2 and JWT - JavaZone 2015
 
1 of 39
Open APIs for Open Minds Example of IdM authentication through use cases Fernando López Aguilar (fla@tid.es, @flopezaguilar)
Content 1. Objectives of this presentation. 2. Scenario 1: Authenticate a Portal Web using the IdM and knowing user credentials. 3. Scenario 2: Authenticate a Portal Web using the IdM and unknowing user credentials. 4. Reference Information. 1
Objectives of this presentation 2
Objectives of this presentation Purpose: develop via 2 Use Cases the management of the IdM which allows users familiarizing with it. All the steps was checked internally and work properly. Change the IP addresses for your own instance of IdM in order to translate to the presentation to your instance. At the end of the presentation, you can find references to more documentation. Other scenario? Translate it to us and we will try to help you. 3
Scenario 1: Authenticate a Portal Web using the IdM and knowing user credentials. 4
Scenario 1: definition We want to create a web application in order to access to an application. We want that the portal could be authenticated using the IdM. We want that the application receive a token of the portal and we want to validate it before make any other operation. The application wants to get also the roles associated to the user. It is not needed to translate to the IdM portal in order to introduce the user/password of the user. The web site knows this data and send them to the IdM.
Web Applications and GEs Core Application 5)Request+ access-token 1) Redirect, Get Access Code 3) request access-token 4) access-token 6) Validate token 7) OK + user info 2) access-code IdM Web App OAuthLibrary IP: a.b.c.d IP: e.f.g.h
Previous steps with IdM portal 1) Create User
Previous steps with IdM portal 2) Add an application with roles
Previous steps with IdM portal 2) Add an application with roles
Previous steps with IdM portal 2) Add an application with roles
Previous steps with IdM portal 2) Add an application with roles
1) Redirect First time, we have to redirect (go) to the IdM web site in order to authorize the access to the new application. https://a.b.c.d/oauth2/authorize?response_type=code&client_id=2
1) Redirect
2) Access code After clicking the “Accept” button, the browser redirect us to a page of our application: http://e.f.g.h/login?code=gW6mpb4Ncfa22YHEf7g6RLqIUyWP_Xwl3IWmr2 QgtXoPZmGDb_ZJud1qfoY2m1CCZAhndKtYpmZAKQAUBBZIdg This is the callback URL specified in the registry of the application (Cloud Portal). We get the “code” value. In this Scenario, we do not need to recover the details of it.
3) Request Access token Para pedir un token de acceso conociendo el user/password desde tu aplicación web: curl -v --insecure -X POST https://a.b.c.d/oauth2/token -H "Content-Type: application/x-www-form-urlencoded" -H "Authorization: Basic MjowYjE5MmUwZDlmMDFkOTgyNjdmMjM2NTM4YzZhNDlmODMxMGNh NmJlNTA2ODg4OTc2MDJhODk1ODVhYmQ2YTYyODRiMGU0MDY4MTBk Mjc2YTYzNmE2Yzg1NTg2MjJhZGFjZjIyYmM3ZDg5MjNiNWVkYWQ2ZmU 0ODhlNmZhOGRjZg==" -d grant_type=password&username=b.rcs@tid.es&password=prueba Donde Authorization es: Base64(Client_ID:Client_Secret) En este caso los valores de la slide 8
4) Access token La llamada previa te devolverá el siguiente mensaje: HTTP/1.1 200 OK Content-Type: application/json { "access_token": "RzE6PnLq6WfAD3okMuO5AwNUiSWbKbeyE6kMcQ3sX2Dk8no- Fqu8VEzAFcmFAPjUnZzHFEj-VSo6CTSniT5gxw", "expires_in": 2591999, "refresh_token": "vEUA4j5oie7DCAzYy9PpXxgV4UsGJZx1B0ooEB- ewumULG_D2DdRs5dAtau-GXWeziWsvAQLEv9OIfG2DXP9lg", "token_type": "bearer" }
5) Request + access-token La llamada que se le quiera mandar a la aplicación pero tiendo en el HEADER el siguiente campo: X-Auth-Token: RzE6PnLq6WfAD3okMuO5AwNUiSWbKbeyE6kMcQ3sX2Dk8no- Fqu8VEzAFcmFAPjUnZzHFEj-VSo6CTSniT5gxw Este se obtiene de la llamada anterior “access_token”
6) Validate X-Auth-Token Lo primero que tendremos que hacer es generar un token de administrador (24h de duración) para poder lanzar las peticiones. curl -vv -s -d '{"auth": {"passwordCredentials": {"username":"pepProxy", "password": "pepProxy"}}}' -H "Content-type: application/json" http://a.b.c.d:4730/v2.0/tokens Ojo de momento esos serían los datos de usuario/password que usa el PEP Proxy para generar el token, en un futuro se podría evaluar mantener un registos de PEP Proxy para que no haya un único dato.
6) Validate X-Auth-Token La llamada anterior os devolverá el siguiente mensaje { "access": { "token": { "expires": "2015-07-09T15:16:07Z", "id": "5b2177e7e1e6592cb7ea168ce9c0e87f" }, "user": { "id": "pepProxy", "name": "pepProxy", "roles_links": [], "username": "pepProxy" } } }
6) Validate X-Auth-Token Una vez que tenemos el token de administrador (una cada 24h) procedemos a validar el access_token que hemos recibido. curl --insecure -H "X-Auth-Token:5b2177e7e1e6592cb7ea168ce9c0e87f" http://a.b.c.d:4731/v2.0/access- tokens/RzE6PnLq6WfAD3okMuO5AwNUiSWbKbeyE6kMcQ3sX2Dk8no- Fqu8VEzAFcmFAPjUnZzHFEj-VSo6CTSniT5gxw X-Auth-Token es el que hemos obtenido en la slide 16 y el access-tokens procede de la slide 13. Si esta operación nos devolviera: • 404  el access_token no es válido • 401  el X-Auth-Token no es válido (no autorizado) • 403  el X-Auth-Token no es válido (caducado)
6) Validate X-Auth-Token Si no hay error devolverá: { "actorId": 1, "displayName": "prueba", "email": "b.rcs@tid.es", "id": 1, "nickName": "prueba", "organizations": [ { "id": 1, "name": "prueba", "roles": [ { "id": "8db87ccbca3b4d1ba4814c3bb0d63aab", "name": "Member" …
6) Validate X-Auth-Token … } ] } ], "roles": [ { "id": 5, "name": "Provider" } ] } Dónde se pueden observar los roles del usuario asociados a la organización (en rojo) y asociados a la aplicación (en azul).
Scenario 2: Authenticate a Portal Web using the IdM and unknowing user credentials. 23
Scenario 2: definition It is the same that the previous scenario. • From slide 7 to 14, they are the same operations. BUT the portal does not now the credentials of the users. • Need to redirect to the IdM portal in order to introduce them. • The IdM portal send the authorization to the portal.
Web Applications and GEs Core Application 5)Request+ access-token 1) Redirect, Get Access Code 3) request access-token 4) access-token 6) Validate token 7) OK + user info 2) access-code IdM Web App OAuthLibrary IP: a.b.c.d IP: e.f.g.h
1) Redirect First time, we have to redirect (go) to the IdM web site in order to authorize the access to the new application. https://a.b.c.d/oauth2/authorize?response_type=code&client_id=2
1) Redirect
2) Access code After clicking the “Accept” button, the browser redirect us to a page of our application: http://e.f.g.h/login?code=ZNYy2HpyO1oMzalQ9- N2T1AIc0tnhTCuCziEG91PiPZPZYkJotzIBfZZlImfw4U7QpAwsgEGw4iakE L0n2FHlg This is the callback URL specified in the registry of the application (Cloud Portal). We get the “code” value, which will be used in order to authenticate user.
3) Request Access token In order to request an access-token, without the knowledge of the credentials of the user: curl -v --insecure -X POST https://a.b.c.d/oauth2/token -H "Content-Type: application/x-www-form-urlencoded" -H "Authorization: Basic MjowYjE5MmUwZDlmMDFkOTgyNjdmMjM2NTM4YzZhNDlmODMxMGNh NmJlNTA2ODg4OTc2MDJhODk1ODVhYmQ2YTYyODRiMGU0MDY4MTBk Mjc2YTYzNmE2Yzg1NTg2MjJhZGFjZjIyYmM3ZDg5MjNiNWVkYWQ2ZmU 0ODhlNmZhOGRjZg==" -d "grant_type=authorization_code&code=ZNYy2HpyO1oMzalQ9- N2T1AIc0tnhTCuCziEG91PiPZPZYkJotzIBfZZlImfw4U7QpAwsgEGw4iakE L0n2FHlg&redirect_uri=http://localhost/login” Where Authorization es: Base64(Client_ID:Client_Secret)
3) Request Access token Where Authorization es: Base64(Client_ID:Client_Secret) From the slide 8 And code is the value obtained in slide 27
4) Access token The previous request will return the following information: HTTP/1.1 200 OK Content-Type: application/json { "access_token": "3- EoxEo3tUas9tQJvxnDsAqkUEi38Ftmy5Ou_vPWNAtA9qyusJdP1LCB835b4 WOB80_XLUziWOFdCs7qSHELlA", "expires_in": 2591999, "refresh_token": "vEUA4j5oie7DCAzYy9PpXxgV4UsGJZx1B0ooEB- ewumULG_D2DdRs5dAtau-GXWeziWsvAQLEv9OIfG2DXP9lg", "token_type": "bearer" }
5) Request + access-token The next request should be done with this X-Auth-Token value: X-Auth-Token: 3- EoxEo3tUas9tQJvxnDsAqkUEi38Ftmy5Ou_vPWNAtA9qyusJdP1LCB835b4 WOB80_XLUziWOFdCs7qSHELlA From the access-token field from the precious request.
6) Validate X-Auth-Token Assuming that you have a vaild token (see slides 18 &19, remember that it is 24 hour vaild only), we can validate the token that we have received in the X-Auth- Token. curl --insecure -H "X-Auth-Token:5b2177e7e1e6592cb7ea168ce9c0e87f" http://a.b.c.d:4731/v2.0/access-tokens/3- EoxEo3tUas9tQJvxnDsAqkUEi38Ftmy5Ou_vPWNAtA9qyusJdP1LCB835b4 WOB80_XLUziWOFdCs7qSHELlA X-Auth-Token corresponds to the token obtained in slide 18 & 19 and access-token comes from slide 30. It could return the following messages is something is wrong: • 404  Access_token not valid • 401  X-Auth-Token not valid (unauthorized) • 403  X-Auth-Token not valid (expired)
6) Validate X-Auth-Token Si no hay error devolverá: { "actorId": 1, "displayName": "prueba", "email": "b.rcs@tid.es", "id": 1, "nickName": "prueba", "organizations": [ { "id": 1, "name": "prueba", "roles": [ { "id": "8db87ccbca3b4d1ba4814c3bb0d63aab", "name": "Member" …
6) Validate X-Auth-Token … } ] } ], "roles": [ { "id": 5, "name": "Provider" } ] } In the same way that was shown in slides 5 & 6.
fiware-lab-help@lists.fi-ware.org 36
Esquema de pasos de ejecución IdM
 http://fi-ppp.eu  http://fi-ware.eu  Follow @Fiware on Twitter ! Thanks ! 38

More Related Content

Esquema de pasos de ejecución IdM

  • 1. Open APIs for Open Minds Example of IdM authentication through use cases Fernando López Aguilar (fla@tid.es, @flopezaguilar)
  • 2. Content 1. Objectives of this presentation. 2. Scenario 1: Authenticate a Portal Web using the IdM and knowing user credentials. 3. Scenario 2: Authenticate a Portal Web using the IdM and unknowing user credentials. 4. Reference Information. 1
  • 3. Objectives of this presentation 2
  • 4. Objectives of this presentation Purpose: develop via 2 Use Cases the management of the IdM which allows users familiarizing with it. All the steps was checked internally and work properly. Change the IP addresses for your own instance of IdM in order to translate to the presentation to your instance. At the end of the presentation, you can find references to more documentation. Other scenario? Translate it to us and we will try to help you. 3
  • 5. Scenario 1: Authenticate a Portal Web using the IdM and knowing user credentials. 4
  • 6. Scenario 1: definition We want to create a web application in order to access to an application. We want that the portal could be authenticated using the IdM. We want that the application receive a token of the portal and we want to validate it before make any other operation. The application wants to get also the roles associated to the user. It is not needed to translate to the IdM portal in order to introduce the user/password of the user. The web site knows this data and send them to the IdM.
  • 7. Web Applications and GEs Core Application 5)Request+ access-token 1) Redirect, Get Access Code 3) request access-token 4) access-token 6) Validate token 7) OK + user info 2) access-code IdM Web App OAuthLibrary IP: a.b.c.d IP: e.f.g.h
  • 8. Previous steps with IdM portal 1) Create User
  • 9. Previous steps with IdM portal 2) Add an application with roles
  • 10. Previous steps with IdM portal 2) Add an application with roles
  • 11. Previous steps with IdM portal 2) Add an application with roles
  • 12. Previous steps with IdM portal 2) Add an application with roles
  • 13. 1) Redirect First time, we have to redirect (go) to the IdM web site in order to authorize the access to the new application. https://a.b.c.d/oauth2/authorize?response_type=code&client_id=2
  • 15. 2) Access code After clicking the “Accept” button, the browser redirect us to a page of our application: http://e.f.g.h/login?code=gW6mpb4Ncfa22YHEf7g6RLqIUyWP_Xwl3IWmr2 QgtXoPZmGDb_ZJud1qfoY2m1CCZAhndKtYpmZAKQAUBBZIdg This is the callback URL specified in the registry of the application (Cloud Portal). We get the “code” value. In this Scenario, we do not need to recover the details of it.
  • 16. 3) Request Access token Para pedir un token de acceso conociendo el user/password desde tu aplicación web: curl -v --insecure -X POST https://a.b.c.d/oauth2/token -H "Content-Type: application/x-www-form-urlencoded" -H "Authorization: Basic MjowYjE5MmUwZDlmMDFkOTgyNjdmMjM2NTM4YzZhNDlmODMxMGNh NmJlNTA2ODg4OTc2MDJhODk1ODVhYmQ2YTYyODRiMGU0MDY4MTBk Mjc2YTYzNmE2Yzg1NTg2MjJhZGFjZjIyYmM3ZDg5MjNiNWVkYWQ2ZmU 0ODhlNmZhOGRjZg==" -d grant_type=password&username=b.rcs@tid.es&password=prueba Donde Authorization es: Base64(Client_ID:Client_Secret) En este caso los valores de la slide 8
  • 17. 4) Access token La llamada previa te devolverá el siguiente mensaje: HTTP/1.1 200 OK Content-Type: application/json { "access_token": "RzE6PnLq6WfAD3okMuO5AwNUiSWbKbeyE6kMcQ3sX2Dk8no- Fqu8VEzAFcmFAPjUnZzHFEj-VSo6CTSniT5gxw", "expires_in": 2591999, "refresh_token": "vEUA4j5oie7DCAzYy9PpXxgV4UsGJZx1B0ooEB- ewumULG_D2DdRs5dAtau-GXWeziWsvAQLEv9OIfG2DXP9lg", "token_type": "bearer" }
  • 18. 5) Request + access-token La llamada que se le quiera mandar a la aplicación pero tiendo en el HEADER el siguiente campo: X-Auth-Token: RzE6PnLq6WfAD3okMuO5AwNUiSWbKbeyE6kMcQ3sX2Dk8no- Fqu8VEzAFcmFAPjUnZzHFEj-VSo6CTSniT5gxw Este se obtiene de la llamada anterior “access_token”
  • 19. 6) Validate X-Auth-Token Lo primero que tendremos que hacer es generar un token de administrador (24h de duración) para poder lanzar las peticiones. curl -vv -s -d '{"auth": {"passwordCredentials": {"username":"pepProxy", "password": "pepProxy"}}}' -H "Content-type: application/json" http://a.b.c.d:4730/v2.0/tokens Ojo de momento esos serían los datos de usuario/password que usa el PEP Proxy para generar el token, en un futuro se podría evaluar mantener un registos de PEP Proxy para que no haya un único dato.
  • 20. 6) Validate X-Auth-Token La llamada anterior os devolverá el siguiente mensaje { "access": { "token": { "expires": "2015-07-09T15:16:07Z", "id": "5b2177e7e1e6592cb7ea168ce9c0e87f" }, "user": { "id": "pepProxy", "name": "pepProxy", "roles_links": [], "username": "pepProxy" } } }
  • 21. 6) Validate X-Auth-Token Una vez que tenemos el token de administrador (una cada 24h) procedemos a validar el access_token que hemos recibido. curl --insecure -H "X-Auth-Token:5b2177e7e1e6592cb7ea168ce9c0e87f" http://a.b.c.d:4731/v2.0/access- tokens/RzE6PnLq6WfAD3okMuO5AwNUiSWbKbeyE6kMcQ3sX2Dk8no- Fqu8VEzAFcmFAPjUnZzHFEj-VSo6CTSniT5gxw X-Auth-Token es el que hemos obtenido en la slide 16 y el access-tokens procede de la slide 13. Si esta operación nos devolviera: • 404  el access_token no es válido • 401  el X-Auth-Token no es válido (no autorizado) • 403  el X-Auth-Token no es válido (caducado)
  • 22. 6) Validate X-Auth-Token Si no hay error devolverá: { "actorId": 1, "displayName": "prueba", "email": "b.rcs@tid.es", "id": 1, "nickName": "prueba", "organizations": [ { "id": 1, "name": "prueba", "roles": [ { "id": "8db87ccbca3b4d1ba4814c3bb0d63aab", "name": "Member" …
  • 23. 6) Validate X-Auth-Token … } ] } ], "roles": [ { "id": 5, "name": "Provider" } ] } Dónde se pueden observar los roles del usuario asociados a la organización (en rojo) y asociados a la aplicación (en azul).
  • 24. Scenario 2: Authenticate a Portal Web using the IdM and unknowing user credentials. 23
  • 25. Scenario 2: definition It is the same that the previous scenario. • From slide 7 to 14, they are the same operations. BUT the portal does not now the credentials of the users. • Need to redirect to the IdM portal in order to introduce them. • The IdM portal send the authorization to the portal.
  • 26. Web Applications and GEs Core Application 5)Request+ access-token 1) Redirect, Get Access Code 3) request access-token 4) access-token 6) Validate token 7) OK + user info 2) access-code IdM Web App OAuthLibrary IP: a.b.c.d IP: e.f.g.h
  • 27. 1) Redirect First time, we have to redirect (go) to the IdM web site in order to authorize the access to the new application. https://a.b.c.d/oauth2/authorize?response_type=code&client_id=2
  • 29. 2) Access code After clicking the “Accept” button, the browser redirect us to a page of our application: http://e.f.g.h/login?code=ZNYy2HpyO1oMzalQ9- N2T1AIc0tnhTCuCziEG91PiPZPZYkJotzIBfZZlImfw4U7QpAwsgEGw4iakE L0n2FHlg This is the callback URL specified in the registry of the application (Cloud Portal). We get the “code” value, which will be used in order to authenticate user.
  • 30. 3) Request Access token In order to request an access-token, without the knowledge of the credentials of the user: curl -v --insecure -X POST https://a.b.c.d/oauth2/token -H "Content-Type: application/x-www-form-urlencoded" -H "Authorization: Basic MjowYjE5MmUwZDlmMDFkOTgyNjdmMjM2NTM4YzZhNDlmODMxMGNh NmJlNTA2ODg4OTc2MDJhODk1ODVhYmQ2YTYyODRiMGU0MDY4MTBk Mjc2YTYzNmE2Yzg1NTg2MjJhZGFjZjIyYmM3ZDg5MjNiNWVkYWQ2ZmU 0ODhlNmZhOGRjZg==" -d "grant_type=authorization_code&code=ZNYy2HpyO1oMzalQ9- N2T1AIc0tnhTCuCziEG91PiPZPZYkJotzIBfZZlImfw4U7QpAwsgEGw4iakE L0n2FHlg&redirect_uri=http://localhost/login” Where Authorization es: Base64(Client_ID:Client_Secret)
  • 31. 3) Request Access token Where Authorization es: Base64(Client_ID:Client_Secret) From the slide 8 And code is the value obtained in slide 27
  • 32. 4) Access token The previous request will return the following information: HTTP/1.1 200 OK Content-Type: application/json { "access_token": "3- EoxEo3tUas9tQJvxnDsAqkUEi38Ftmy5Ou_vPWNAtA9qyusJdP1LCB835b4 WOB80_XLUziWOFdCs7qSHELlA", "expires_in": 2591999, "refresh_token": "vEUA4j5oie7DCAzYy9PpXxgV4UsGJZx1B0ooEB- ewumULG_D2DdRs5dAtau-GXWeziWsvAQLEv9OIfG2DXP9lg", "token_type": "bearer" }
  • 33. 5) Request + access-token The next request should be done with this X-Auth-Token value: X-Auth-Token: 3- EoxEo3tUas9tQJvxnDsAqkUEi38Ftmy5Ou_vPWNAtA9qyusJdP1LCB835b4 WOB80_XLUziWOFdCs7qSHELlA From the access-token field from the precious request.
  • 34. 6) Validate X-Auth-Token Assuming that you have a vaild token (see slides 18 &19, remember that it is 24 hour vaild only), we can validate the token that we have received in the X-Auth- Token. curl --insecure -H "X-Auth-Token:5b2177e7e1e6592cb7ea168ce9c0e87f" http://a.b.c.d:4731/v2.0/access-tokens/3- EoxEo3tUas9tQJvxnDsAqkUEi38Ftmy5Ou_vPWNAtA9qyusJdP1LCB835b4 WOB80_XLUziWOFdCs7qSHELlA X-Auth-Token corresponds to the token obtained in slide 18 & 19 and access-token comes from slide 30. It could return the following messages is something is wrong: • 404  Access_token not valid • 401  X-Auth-Token not valid (unauthorized) • 403  X-Auth-Token not valid (expired)
  • 35. 6) Validate X-Auth-Token Si no hay error devolverá: { "actorId": 1, "displayName": "prueba", "email": "b.rcs@tid.es", "id": 1, "nickName": "prueba", "organizations": [ { "id": 1, "name": "prueba", "roles": [ { "id": "8db87ccbca3b4d1ba4814c3bb0d63aab", "name": "Member" …
  • 36. 6) Validate X-Auth-Token … } ] } ], "roles": [ { "id": 5, "name": "Provider" } ] } In the same way that was shown in slides 5 & 6.
  • 39.  http://fi-ppp.eu  http://fi-ware.eu  Follow @Fiware on Twitter ! Thanks ! 38

Editor's Notes

  1. 57, 67 y 68 hay que cambiarlos…
  2. Hay que validar el correo para dar de alta finalmente al usuario
  3. Python Base64.b64encode(‘Client ID:Client Secret’)
  4. Python Base64.b64encode(‘Client ID:Client Secret’)