Hi, +1, this way it would not break anything currently working.
Thanks, -Suresh On Sun, Oct 6, 2013 at 3:40 PM, Johann Nallathamby <[email protected]> wrote: > +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* > -- 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
