Hi Prabath, The current OAuth2TokenValidationService is a proprietary implementation and request-response messages are not following any standard. The point of using the introspection here is to standarize the request-response messages. The specification allows the requester to pass extra context parameters to the endpoint and endpoint can do the validation of the token and return token metadata only if the token is valid. Checking the validitiy of the token is out of scop of the specification, however the parameter "active" is used to return the validity of the token to the requester. We can have pluggable token validators to be used in different requirements.
For ex:- A token T1 issued for the app A with scope S1 will not be a valid token in the context where the same app A1 is using the token T1 to access a resource which require scope S2. This decision can be taken by the endpoint and return a response having *false *for the paremeter "active". Thanks, -Suresh On Mon, Oct 7, 2013 at 7:51 PM, Prabath Siriwardena <[email protected]>wrote: > 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 > > -- 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
