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]
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
