SI TP3 G05 - UMA

User-Managed Access (UMA)

1. Introdução O Acesso Controlado pelo Utilizador, tradução livre do inglês (UMA – User-Managed Acess) é um perfil do OAuth 2.0 desenhado para unificar num ponto central de controlo a definição de como o dono de determinado recurso (geralmente um utilizador web) gere o acesso a este por parte de clientes. Quando o owner e client se encontram em diferentes servidores a autorização é delegada a um gestor central.

2. Terminologia UMA introduziu novos termos à terminologia do OAuth, entre eles: Resource Owner - O utilizador web comum, aquele que possui os recursos. Pode ser uma pessoa normal ou uma empresa. Client – Aplicação cliente que acede aos recursos com autorização do dono dos mesmos. Requesting Party – Um utilizador (pessoa ou grupo) que pretende aceder a um recurso através de uma aplicação cliente. Permission – Descreve operações em recursos. Um recurso requer permissões e um utilizador tem um conjunto de permissões. Token – Um descritor de acessos que pode ser transmitido entre utilizadores para oferecer permissões temporárias.

[LI-51D] Grupo 5 I

3. Distribuição de controlo

Todo o software da estrutura do UMA (servidor de autorização, controlo de recursos e os próprios clientes) deve ser construído com interoperabilidade em mente. De modo a normalizar este aspecto, as comunicações devem todas ser feitas via HTTP.

4. Servidor de autorização

O servidor de autorização deve funcionar sobre HTTP protegido por OAuth. Se uma entidade pretende comunicar com o servidor de autorização deve utilizar o scope “uma_authorization” Dados de configuração do servidor de autorização: A configuração do servidor de autorização é feita através de um ficheiro JSON com as propriedades necesárias, entre elas: version: Obrigatória, é a versão do UMA em utilização pelo servidor de autorização central. O valor tem que ser a string “1.0”. issuer: Obrigatório. URI indicando a parte operacional do servidor de autorização. token_endpoint: Obrigatório. O URI onde uma entidade requer um token de acesso ao servidor de autorização. authorization_endpoint: Obrigatório. O URI onde o servidor de recursos recolhe a consenso do dono do recurso.

[LI-51D] Grupo 5 II

O servidor suporta muitos mais dados, pelo que os restantes serão apresentados no exemplo seguinte. Exemplo de configuração de dados do servidor de autorização: { "version":"1.0", "issuer":"https://example.com", "pat_profiles_supported":["bearer"], "aat_profiles_supported":["bearer"], "rpt_profiles_supported": ["https://docs.kantarainitiative.org/uma/profiles/umatoken-bearer-1.0"], "pat_grant_types_supported":["authorization_code"], "aat_grant_types_supported":["authorization_code"], "claim_token_profiles_supported":["https://example.com/clai ms/formats/token1"], "dynamic_client_endpoint":"https://as.example.com/dyn_clien t_reg_uri", "token_endpoint":"https://as.example.com/token_uri", "authorization_endpoint":"https://as.example.com/authz_uri" , "requesting_party_claims_endpoint":"https://as.example.com/ rqp_claims_uri", "resource_set_registration_endpoint":"https://as.example.co m/rs/rsrc_uri", "introspection_endpoint":"https://as.example.com/rs/status_ uri", "permission_registration_endpoint":"https://as.example.com/ rs/perm_uri", "rpt_endpoint":"https://as.example.com/client/rpt_uri" } [1]

5. Obter permissão e aceder a um recurso O processo de adquirir autorização começa sempre com o cliente a tentar aceder a um recurso. O servidor pode responder imediatamente, por exemplo se o cliente não tiver permissões suficientes, ou pode introduzir mais uns passos se a tentativa de acesso não for bem sucedida. Guia da interação cliente-servidor: 

Cliente tenta aceder a um recurso o Se o pedido não for acompanhado com um RPT (Request party token) o servidor responde com HTTP 403

[LI-51D] Grupo 5 III

(Forbidden), um ticket de permissão e as instruções para obter o mesmo. o Se o RPT não tiver autorização suficiente o servidor responde com HTTP 403 (Forbidden), um ticket de permissão e as instruções para obter o mesmo.

o Se o RPT tiver autorização suficiente o servidor responde com HTTP 2xx (Sucesso).

O servidor de recursos constroi um ticket temporário com o pedido de permissão para ser enviado ao servidor de autorização.

Exemplo (sem RPT): HTTP/1.1 403 Forbidden WWW-Authenticate: UMA realm="example", as_uri="https://as.example.com" { "ticket": "016f84e8-f9b9-11e0-bd6f-0021cc6004de" }[2]

Este ticket pode ter as informações que o servidor achar necessário uma vez que o seu tempo de vida é curto.

6. Cliente requer dados de autorização

Exemplo de um pedido (com RPT e ticket): POST /authz_request HTTP/1.1 Host: as.example.com Authorization: Bearer jwfLG53^sad$#f { "rpt": "sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv", "ticket": "016f84e8-f9b9-11e0-bd6f-0021cc6004de" }[3]

O servidor de autorização responde de acordo com as restrições que o dono do recurso impôs. Se o pedido for bem sucedido o servidor responde com um RPT que pode ser o mesmo ou um novo. [LI-51D] Grupo 5 IV

Exemplo: HTTP/1.1 200 OK Content-Type: application/json { "rpt": "sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv" }[4]

Se o pedido não for bem sucedido, um destes erros pode ser retornado:

invalid_ticket O ticket não foi encontrado no servidor de autorização

expired_ticket O tempo de vida do ticket expirou

not_authorized O cliente não tem autorização para aceder aos recursos.

need_info O servidor precisa de mais informação para saber se o cliente está autorizado para aceder ao recurso.

request_submitted É necessária a intervenção do dono do recurso.

[LI-51D] Grupo 5 V

7. Esquemas de exemplo:

Fig.1 - Esquema exemplo do UMA [5]

No esquema de exemplo seguinte podemos observar que o utilizador consegue voltar a aplicar as políticas de controlo de acesso já compostas para recursos transferidos de uma aplicação web para outra.

Fig.2 – (1) – Servidor de Autorização , (2) – Utilizador, (3) –Servidor de Recursos, (4) – Clientes, (5) - Recurso [6]

[LI-51D] Grupo 5 VI

Referências [1] https://docs.kantarainitiative.org/uma/ - a 27/12/14 às 13h46 [2] https://docs.kantarainitiative.org/uma/draft-uma-core.html#rfc.section.3.1.1 a 04/01/15 às 20h10 [3] https://docs.kantarainitiative.org/uma/draft-uma-core.html#rfc.section.3.4.1 a 04/01/15 às 20h10 [4] https://docs.kantarainitiative.org/uma/draft-uma-core.html#rfc.section.3.4.1 a 04/01/15 às 20h10 [5] http://kantarainitiative.org/confluence/display/uma/Home a 27/12/14 às 13h58 [6] http://kantarainitiative.org/confluence/display/uma/UMA+Scenarios+and+Use+Cases a 04/01/15 às 18h53

[LI-51D] Grupo 5 VII