Hi Suresh, Can you please explain a bit how we can use introspection specification here ?
Introspection endpoint does not validate the token. It only returns back some metadata about the token. Introspection end point ideally should not return any authorization decisions back - as that is not the concern addressed by it. Thanks & regards, -Prabath On Fri, Oct 4, 2013 at 9:33 PM, Suresh Attanayaka <[email protected]> wrote: > Hi Johann, > > +1 on the idea. Are we extending the existing SOAP API > (OAuth2TokenValidationService) for this or writing a new SOAP API ? My idea > is that we should deprecate the existing API (but not remove) and write a > whole new API just for the sake of backward capability. > > And how about a REST API? the Introspection Specification [1] defines a > standard for this purpose. It allows the requester to define additional > context information in the request to the endpoint [2]. We can extend the > response[2] to return authorization decision as well and probably to return > a JWT(for JWS) instead of a JSON. > > [1] - http://tools.ietf.org/html/draft-richer-oauth-introspection-04 > [2] - > http://tools.ietf.org/html/draft-richer-oauth-introspection-04#section-2.1 > > Thanks, > -Suresh > > > On Wed, Oct 2, 2013 at 2:47 AM, Prabath Siriwardena <[email protected]>wrote: > >> +1 >> >> Currently IS and API-M use two different services for token validation. >> So - lets get rid-of this code duplication first and then work on the >> improvements... >> >> Thanks & regards, >> -Prabath >> >> >> >> On Wed, Oct 2, 2013 at 11:05 AM, Johann Nallathamby <[email protected]>wrote: >> >>> Currently the OAuth2 scopes and resource owner are not verified during >>> the time of access token validation. We simply look at the validity of the >>> access token by checking the expiry time. The validation response however >>> contains the approved scopes and authorized user (resource owner), and its >>> verification is assumed to be handled by the caller (e.g. gateway). >>> >>> This approach does not allow us to centrally manage the authorization. >>> E.g. after receiving the approved scopes and authorized user the caller >>> should make another call to a authorization server (e.g. XACML PDP) to do >>> the authorization based on the received response from the OAuth2 server and >>> the resource the client is trying to access. This adds the overhead of >>> another call from the gateway to an entity in the internal network as well. >>> >>> A much more better approach would be to send the required parameters >>> that are needed to make the authorization decision in the request for >>> access token validation itself. The OAuth server in addition to what it >>> does now, i.e. checking access token validity can do the authorization >>> (scope validation and resource owner validation). E.g. if we have the WSO2 >>> XACML engine installed in the same box and exposed as an OSGi service its >>> going to make lives much better in terms of performance. >>> >>> For this the current OAuth2TokenValdationService API needs to be >>> changed. Currently besides other inputs to identify the token, the only >>> input it receives from the caller which identifies the resource trying to >>> be accessed is the context (String) parameter. However I don't think a >>> single String input is good enough. The authorization for the resource >>> could require other parameter like parameters which are part of the HTTP >>> body. So therefore we need to change the API to accept a key-value pair >>> data structure. >>> >>> For the clients that we have in our platform which calls this service, >>> we should allow the users to implement what needs to be sent over by >>> providing a hook, rather than sending the context alone. >>> >>> Suggestions are welcome. >>> >>> -- >>> Thanks & Regards, >>> >>> *Johann Dilantha Nallathamby* >>> Senior Software Engineer >>> Integration Technologies Team >>> WSO2, Inc. >>> lean.enterprise.middleware >>> >>> Mobile - *+94777776950* >>> Blog - *http://nallaa.wordpress.com* >>> >> >> >> >> -- >> Thanks & Regards, >> Prabath >> >> Mobile : +94 71 809 6732 >> >> http://blog.facilelogin.com >> http://RampartFAQ.com >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Suresh Attanayake > Senior Software Engineer; WSO2 Inc. http://wso2.com/ > Blog : http://sureshatt.blogspot.com/ > Web : http://www.ssoarcade.com/ > Facebook : https://www.facebook.com/IdentityWorld > Twitter : https://twitter.com/sureshatt > LinkedIn : http://lk.linkedin.com/in/sureshatt > Mobile : +94755012060 > Mobile : +01-616-617-1172 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
