Hi All, I had my mid review on the 2nd of July. I have completed the following so far,
- Implemented a tomcat valve [1] to do the access token validation instead of doing it within each OAuth protected endpoint of UMA. By this way it will be possible reuse this valve for all endpoints that require OAuth protection within the User Managed Access 1.0 specification. Further more this could also be used for any other endpoint that is OAuth protected as suggested by my mentor. - Implemented the Authorization API [2]. This requires some more work to complete mainly due to the fact that it depends on data persisted by the Protection API which needs to be implemented next. My work so far can be found at [1], [2] After the discussion with my mentor the next part implementation will be the Protection API which has three endpoints 1. Resource Set Registration Endpoint 2. Permission Set registration Endpoint 3. OAuth Token Introspection Endpoint Resource Set Registration Endpoint will be implemented first. I will update the thread with the details of resource set registration API and its implementation. Feedback and comments will be much appreciated. [1] https://github.com/mefarazath/carbon-identity/tree/gsoc-uma/components/tomcat-valve [2] https://github.com/mefarazath/carbon-identity/tree/gsoc-uma/components/uma On Fri, Jun 19, 2015 at 2:48 PM, Farazath Ahamed <[email protected]> wrote: > 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] > -- *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
