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.

2

Objectives of this presentation

3

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.

4

Scenario 1:

Authenticate a Portal Web using the IdM and knowing user credentials.

5

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) R

eque

st +

acce

ss-to

ken

1) Redirect, Get Access Code

3) request access-token

4) access-token

6) Validate token

7) OK + user info

2) access-code

IdM

Web AppOA

uth

Libra

ry

IP: a.b.c.dIP: e.f.g.h

Previous steps with IdM portal1) Create User

Previous steps with IdM portal2) Add an application with roles

Previous steps with IdM portal2) Add an application with roles

Previous steps with IdM portal2) Add an application with roles

Previous steps with IdM portal2) 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_Xwl3IWmr2QgtXoPZmGDb_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 MjowYjE5MmUwZDlmMDFkOTgyNjdmMjM2NTM4YzZhNDlmODMxMGNhNmJlNTA2ODg4OTc2MDJhODk1ODVhYmQ2YTYyODRiMGU0MDY4MTBkMjc2YTYzNmE2Yzg1NTg2MjJhZGFjZjIyYmM3ZDg5MjNiNWVkYWQ2ZmU0ODhlNmZhOGRjZg==" -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 OKContent-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.

24

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) R

eque

st +

acce

ss-to

ken

1) Redirect, Get Access Code

3) request access-token

4) access-token

6) Validate token

7) OK + user info

2) access-code

IdM

Web AppOA

uth

Libra

ry

IP: a.b.c.dIP: 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-N2T1AIc0tnhTCuCziEG91PiPZPZYkJotzIBfZZlImfw4U7QpAwsgEGw4iakEL0n2FHlg

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 MjowYjE5MmUwZDlmMDFkOTgyNjdmMjM2NTM4YzZhNDlmODMxMGNhNmJlNTA2ODg4OTc2MDJhODk1ODVhYmQ2YTYyODRiMGU0MDY4MTBkMjc2YTYzNmE2Yzg1NTg2MjJhZGFjZjIyYmM3ZDg5MjNiNWVkYWQ2ZmU0ODhlNmZhOGRjZg==" -d "grant_type=authorization_code&code=ZNYy2HpyO1oMzalQ9-N2T1AIc0tnhTCuCziEG91PiPZPZYkJotzIBfZZlImfw4U7QpAwsgEGw4iakEL0n2FHlg&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 OKContent-Type: application/json

{ "access_token": "3-EoxEo3tUas9tQJvxnDsAqkUEi38Ftmy5Ou_vPWNAtA9qyusJdP1LCB835b4WOB80_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_vPWNAtA9qyusJdP1LCB835b4WOB80_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_vPWNAtA9qyusJdP1LCB835b4WOB80_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 

37

http://fi-ppp.eu

http://fi-ware.eu

Follow @Fiware on Twitter !

Thanks !

39