Hi All, The following were discussed during the meeting held on Monday with my mentor,
- Since the two APIs of UMA need to be protected by OAuth, instead of duplicating code to validate the access tokens per endpoint implement a generic component to do this. This would be useful for other endpoints of IS like the SCIM provider as well. The plan is to implement a tomcat valve that would handle validating the access token for protected URLs. - Finish implementing the Authorization API, the tomcat valve for validating access tokens before the mid evaluation along with documentation and PoC On Thu, Jun 11, 2015 at 10:33 PM, Farazath Ahamed <[email protected]> wrote: > 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] > -- *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
