Hi All, After having a discussion with my mentor I am currently working on the Authorization API of the User Managed Access core specification. I have created a doc to include the details related to the Authorization API[1].
The two APIs implemented under the core specification are required to be protected by OAuth2 or OAuth based mechanism. In order to achieve this we decided to come up with a separate component that could be used to protect other REST endpoints exposed by the identity server as well (eg: SCIM) After initial implementations I hope to have to meet my mentor coming Monday to discuss the requirements of the above mentioned implementation to protect REST endpoints with OAuth. [1] https://docs.google.com/document/d/1yiCgJnOhg1oSTQaMFZ_mDe_oNiPLklypFq9HWkFU7fM/edit?usp=sharing On Tue, May 12, 2015 at 11:27 AM, Farazath Ahamed <[email protected]> wrote: > Hi All, > > I am Farasath Ahamed, GSoC 2015 participant for the $subject for WSO2 > Identity Server. First of all let me thank WSO2 for this valuable > opportunity. > > > I though it would be appropriate to give a brief description of the > project. > > User-Managed Access (UMA) is a profile of OAuth 2.0[1]. UMA defines how > resource owners can control protected-resource access by clients operated > by arbitrary requesting parties, where the resources reside on any number > of resource servers, and where a centralized authorization server governs > access based on resource owner policies. This project is to implement UMA > 1.0 support for WSO2 Identity Server by extending the OAuth 2.0 > authorization framework implementation. > > A detailed description of the proposed project can be found at [2] > > Below is a diagram that explains the flow in User Managed Access 1.0 > specification. > > > > > 1. Resource Server registers resource sets and scopes > 2. Client request access to protected resource on behalf of the > requesting party > 3. Resource Server registers attempted access(Resource + Scope) > 4. Authorization Server returns a permission ticket > 5. Resource Server returns a HTTP 403 with as_uri and permission ticket > 6. Client requests authorization data providing the permission ticket > 7. Authorization Server gives RPT after gathering claims if necessary > 8. Clients requests for the resource with RPT > 9. Resource Server introspects RPT at the Authorization Server > 10. Authorization Server returns token status > 11. Resource Server returns HTTP 20x response > > > Here's a summary of my project plan, you can refer to the GSoC proposal at > [2] for a more detailed project plan > > The User Managed Access profile access consists of two main APIs. > > > 1. Protection API > > this API protected by OAuth or an OAuth based mechanism.This API provides > Endpoints > > > - Place resources under protection > - Register permissions related to resources > - Token introspection of RPT(Request Party Tokens which are required > to access an UMA protected resource) > > To access this API you require an PAT(Protection Access Token) which is > simply an OAuth access token with a scope of "uma_protection" > > 2. Authorization API > > this API protected by OAuth or an OAuth based mechanism. To access this > API you need a AAT(Authorization Access Token) which is simply and OAuth > access token with a scope "uma_authorization" > > An authorization client can get an RPT(Request Party Token) from an > Authorization after exchanging claims. > > > > In addition to these APIs, i also have planned to implement the OAuth > Dynamic client registration for WSO2 Identity Server which is an optional > profile for UMA 1.0. > > > I met with my mentor Johann to have an initial discussion on how to > proceed with the project. After the discussion we decided to implement UMA > 1.0 specification in 3 phases. > > Phase 1 > > Implement the Authorization API > > Implement the OAuth Dynamic Client Registration Specification > > > Phase 2 > > Implement the Protection API > > > - Resource Set Registration > - Permission Set Registration > - Token Introspection > > Phase 3 > > Integration of two APIs > > > > I was asked to come up with a design and class diagram for Authorization > API which would be the first phase of implementation. I was also asked to > come up with the DB schema to be used by the Authorization API. I will > update the thread with the design and class diagram. > > > Your comments and feedback would be appreciated :) > > > [1] https://docs.kantarainitiative.org/uma/draft-uma-core.html > [2] > https://docs.google.com/document/d/1C1y7iF1IUl88CZGK0bFGo5Iy-23LVh-NWqO3OvJbViM/edit > > -- > *A.Farasath Ahamed* > Undergraduate | Department of Computer Science and Engineering,University > of Moratuwa > Article Writer | MoraSpirit > Mobile: +94 777 603 866 > Blog: http://thepseudocode.blogspot.com > E-Mail: [email protected] > -- *A.Farasath Ahamed* Undergraduate | Department of Computer Science and Engineering,University of Moratuwa Article Writer | MoraSpirit Mobile: +94 777 603 866 Blog: http://thepseudocode.blogspot.com E-Mail: [email protected]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
