+1 for adding introspection endpoint. As you say we can provide a hook to extend the standard response with implementation specific attributes (e.g. in API Manager we have attributes such as application, version, etc.).
However I don't think we can change the response to a JWT, since it will violate the spec. I understand your concern to have signatures for integrity. The integrity of the communication between the caller and the introspection endpoint will be basically provided by SSL. However integrity of the response becomes important if we think of the caller passing this response to the resource server and the resource server wants to validate these claims. This is actually why we return the JWT as part of the OAuth2TokenValidation endpoint. So my suggestion is to have the JWT encoded in to the JSON response. In other words, the introspection response would be JSON with standard attributes in the specification + additional attributes provided using a hook + the JWT itself as an attribute. In the case of API Manager this JWT can be extracted and sent to the back end services as usual. WDYT? 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 > -- 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
