Hi Prabath, Sumedha, This draft looks good but limited to a single domain of trust. That is the draft assumes all the resource servers are in one domain and there is only a single authorization server. In that case yes, access tokens can be re-delegated. What if the scenario is that the resource servers exist in different domains and each of them have different authorization servers?
This is where I think the JWT profile for OAuth2.0 [1] comes in to the scenario. We've already got part of this scenario covered in our products where we generate a JWT during access token validation. The next step is to support the above profile so that the first backend system can exchange the JWT for access tokens from other authorization servers to access their resource servers. In this approach the client ID and resource owner name are available in the JWT as attributes and the authorization servers can verify its integrity by validating the JSON Web Signature (JWS). I think even the SAML2 Assertion profile for OAuth2 could solve this in a similar manner. But in terms of implementation we will need to support generating a SAML2 assertion instead of the current JWT so that the first backend system can exchange this SAML2 assertion to an access token using the SAML2 assertion grant type. Both of these solutions should equally work, but in terms of implementation have different areas to be covered. Do you see any gaps that any of the above 2 solutions cannot address in Sumedha's requirement? [1] http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-06 On Wed, Sep 11, 2013 at 6:12 PM, Sumedha Rubasinghe <[email protected]>wrote: > Thanks Prabath. Will read the spec & come up with necessary changes. > > > On Wed, Sep 11, 2013 at 4:08 PM, Prabath Siriwardena <[email protected]>wrote: > >> Hi Sumedha, >> >> This needs to be better modeled after "A Method of Bearer Token >> Redelegation and Chaining for OAuth 2" >> >> http://tools.ietf.org/id/draft-richer-oauth-chain-00.txt >> >> The grant type needs to be urn:ietf:params:oauth:grant_type:redelegate >> >> And also - we should not provide a refresh token in the response. >> >> Thanks & regards, >> -Prabath >> >> >> On Mon, Sep 9, 2013 at 9:36 PM, Sumedha Rubasinghe <[email protected]>wrote: >> >>> *Pattern* >>> There are multiple backend systems having its own authentication and >>> authorization mechanisms. These sub systems do not trust each other. >>> >>> In order to fulfill an API invocation from an end user, several of these >>> back ends need to be accessed. The number of internal systems that need to >>> be accessed is transparent to application developer and only known to API >>> publisher and implementor. However for statistical reason access need to >>> happen as if its coming from the end user + internal backend system. >>> >>> Thus comes the need for delegating access on behalf of end user. >>> >>> *Implementation* >>> Initial API access will happen through an OAuth2 token (obtained on >>> behalf of end user through standard grant types). >>> This API call will reach first backend system. When this backend system >>> needs to access some other system, it will obtain an OAuth2 token on behalf >>> of the end user. However, at this point only original OAuth2 token is >>> available to represent end user. >>> >>> Thus token to second system is obtained by passing, >>> *consumer key + consumer secret + OAuth2 token passed into access first >>> system* >>> >>> This combination is not supported by any of standard grant types defined >>> in OAuth2. Thus we would support the above pattern using a extended grant >>> type called "trusted_delegation". >>> >>> The syntax for invoking this grant type is as follows: >>> *HTTP Header:* >>> Authorization : Basic 'Base64.encode(consumer key . Consumer secret)' >>> >>> *Request parameters:* >>> grant_type=trusted_delegation&enduser_token=wsdr23djdedv >>> >>> Response would be as follows: >>> { >>> "token_type":"bearer" >>> ,"expires_in":3600 >>> ,"refresh_token":"f592b7403f3225d22f4b8e8510928e47" >>> ,"access_token":"5abbabd324fdcd697591b83c7b6eef3" >>> } >>> >>> >>> Thanks to Prabath for help on solidifying solution criteria and grant >>> type name. >>> I have implemented the first draft and will schedule a code review >>> session. >>> >>> >>> *Pending:* >>> 1. Revoke - when end user decides to revoke his token, all tokens >>> issued on behalf of him (and stored on intermediate sub-systems) should be >>> revoked. >>> >>> >>> -- >>> /sumedha >>> b : bit.ly/sumedha >>> >> >> >> >> -- >> Thanks & Regards, >> Prabath >> >> Mobile : +94 71 809 6732 >> >> http://blog.facilelogin.com >> http://RampartFAQ.com >> > > > > -- > /sumedha > b : bit.ly/sumedha > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks & Regards, *Johann Dilantha Nallathamby* Senior Software Engineer Integration Technologies Team WSO2, Inc. lean.enterprise.middleware Mobile - *+94777776950* Blog - *http://nallaa.wordpress.com*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
