On Thu, Aug 31, 2017 at 8:08 PM, Isuri Anuradha <is...@wso2.com> wrote:
> Hi all, > > UMA 2.0 is a new federated authorization standard protocol approved by the > Kantara Initiative[1]. It is built on top of OAuth 2.0. UMA 2.0 enables > clients to access protected resources which are owned by a resource owner > who can set up his/her own policies.This project focuses on implementing > UMA 2.0 support for WSO2 Identity Server by extending the OAuth 2.0 > authorization framework implementation. > > > Following is a diagram depicting the basic UMA workflow. > > > > > - > > PAT-Protection API Token > - > > RPT- Requesting Party Token > - > > PCT-Persisted Claim Token > - > > PT- Permission Ticket > > > > Initially the Resource owner has written a set of policies to the > Authorization Server. The Resource Server has registered resource sets and > scopes in the Authorization Server. > > 1. > > Client request access to protected resource on behalf of the > requesting party. > 2. > > Resource Server registers attempted access (Resource + Scope). > 3. > > Authorization Server returns a permission ticket. > 4. > > Resource Server returns permission ticket with as_uri. > 5. > > Client validates himself as a valid user by the permission ticket with > client credentials. > 6. > > Authorization Server gives RPT & PCT after gathering claims if > necessary. > 7. > > Clients requests for the resource with RPT. > 8. > > Resource Server introspects RPT at the Authorization Server. > 9. > > Authorization Server returns JSON response. > 10. > > Client receives the requested resource. > > > The User Managed Access profile consists of two main APIs. > > > 1. > > Protection API > > > The protection API is protected by OAuth or an authentication protocol > based on OAuth. The protection API token (PAT) involved here binds the > Resource Server to the Authorization Server. > > Protection API consists of 3 endpoints. > > 1. > > Resource registration endpoint > 2. > > Permission registration endpoint > 3. > > Token introspection endpoint > > > > 2. Authorization API > > Client sends a request to the Resource Server seeking access to a > protected resource under UMA. The client is required to access the > authorization API exposed by Authorization Server to prove himself as a > valid user. > > This API is also protected by OAuth or an OAuth based mechanism. > > > We will be implementing UMA 2.0 specification under the 3 phases mentioned > below. > > > Phase 1 > > Designing and implementing Resource registration endpoint. > > > 1. > > Send request to Authorization Server to register resources. > 2. > > Respond with a status message that includes an _id property. > > > > > Designing and implementing Permission registration endpoint. > > > > 1. > > The client attempts to access the protected resource . This attempted > request will have no RPT, or has an invalid RPT or insufficient > authorization data associated with the RPT as determined by checking the > RPT status. > 2. > > Next the request is sent to the protection API's permission > registration endpoint for the registration corresponding to the relevant > Authorization Server. > 3. > > Authorization Server issues and sends a PT to the Resource Server. > 4. > > The client receives the PT with the Authorization Server location from > the resource server. > > > > Phase 2 > > Designing and implementing UMA grant type. > > Phase 3 > > Designing and implementing policies based on Authorization server. > > > Your comments and feedback would be appreciated. > > > [1]https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-01.html > > > Thank you. > > Best regards, > > -------------------- > Isuri Anuradha > Trainne software engineer | WSO2 > > Emaii : is...@wso2.com > Mobile : +94775941280 <+94%2077%20594%201280> > web :http://wso2.com > > <http:///wso2.com> >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
