[mitreid-connect] Token Introspection example usage

Wed May 28 11:17:45 EDT 2014

The token introspection filter is not meant for SSO. It’s meant for protected resources that are hosted separately from their authorization server and that need to do a live check of the token. What happens is that the OAuth client gets a token (using whatever normal OAuth method it wants) and uses that token to call a protected resource, just like regular OAuth. Then the protected resource has to decide whether or not to honor the request given the token that was passed in with it. When doing token introspection, the protected resource reads the token off the wire from the client’s request, then POSTs the token to the authorization server (along with the protected resource’s own credentials). The authorization server returns a JSON object that tells the protected resource whether or not the token is currently active, along with what scopes are attached to it, what user approved it, what client it was approved for, etc. Basically, all the meta data surrounding a token that the protected resource would need in order to make an authorization decision.

In Spring Security OAuth, this “check the token” step is made using the TokenServices bean, which is why our introspecting service implements that interface and is wired in like that. Common alternatives to token introspection including parsing the token itself (if you know the format and know its contents) or doing a database lookup on the token value (if you’ve got access to the token store directly). 

So no, I don’t think the introspection filter is really a good fit for the kind of thing you’re looking to do below. From what I can see, you’d be better off trying to do one of the following:

 - Have a “gateway” application that authenticates the user and passes the ID Token down through the rest of the applications. This is useful only if your applications are very tightly coupled with each other and you can absolutely always trust the gateway. It’s got a downside of passing around the ID Token — a standalone assertion of the user — between different applications, which could cause data leakage. And there’s no “standard” way to do this, though there are a number of gateway platforms out there that do this kind of proxying (like the Apache auth modules, for instance, or just about any enterprise style SSO solution). 

 - Have a single “UI” application that calls the rest of the applications as services. The UI can log in the user and get OAuth access tokens for talking to the rest of the service applications. This means the user is effectively only logging into one application but giving that application access to a number of different services on the user’s behalf — classic OAuth delegation.

 - Have each application authenticate the user separately, but use an account chooser and application whitelisting to manage the user experience. This is much more flexible because it allows for the applications to all have their own ID Tokens and not have to share them (making for better security as well), and each application can just speak the standard OpenID Connect protocol directly to the IdP without having to write something to a gateway. On the downside, this requires more setup in order to get a smooth user experience between applications.

I’d recommend the last one for having the most robust architecture, personally, but it really depends on the kind of application you’re after and what kind of engineering you’re looking to do.

Hope this helps,
 — Justin

On May 28, 2014, at 10:40 AM, Duc Nguyen <nguyen.d.duc at gmail.com> wrote:

> Thanks for the pointers. I'm still trying to get it working but can I ask about the use-case that the Token Introspecting Client Filter is meant for? We're trying to implement sso as follows:
> User logs into portal (portal web app authenticates with Authorization Server)
> User credentials determine the list of applications (all web apps) the user has access to
> Clicking on an app automatically single-sign-ons the user (no confirmation)
> I thought that we could use Token Introspecting Client Filter in step 3?
> 
> Here's my spring config, but no luck in getting the filter to kick-in. I'm new to all this so thanks for the patience.
> 
>     <security:http pattern="/introspect"
>                    create-session="stateless"
>                    entry-point-ref="oauthAuthenticationEntryPoint"
>                    use-expressions="true">
>         <security:intercept-url pattern="/introspect" access="permitAll" />
>         <security:custom-filter before="PRE_AUTH_FILTER" ref="resourceServerFilter" />
>     </security:http>
>     <oauth2:resource-server id="resourceServerFilter" token-services-ref="introspectingService" />
>     <bean id="introspectingService" class="org.mitre.oauth2.introspectingfilter.IntrospectingTokenService">
>         <property name="introspectionConfigurationService" ref="defaultIntrospectionConfigurationService"/>
>         <property name="introspectionAuthorityGranter" ref="defaultIntrospectionAuthorityGranter"/>
>     </bean>
>     <bean class="org.mitre.oauth2.introspectingfilter.service.impl.StaticIntrospectionConfigurationService" id="defaultIntrospectionConfigurationService">
>         <property name="introspectionUrl" value="http://localhost:8080/openid-connect-server-webapp/introspect" />
>         <property name="clientConfiguration">
>             <bean class="org.mitre.oauth2.model.RegisteredClient">
>                 <property name="clientId" value="client"/>
>                 <property name="clientSecret" value="secret"/>
>             </bean>
>         </property>
>     </bean>
>     <bean class="org.mitre.oauth2.introspectingfilter.service.impl.SimpleIntrospectionAuthorityGranter" id="defaultIntrospectionAuthorityGranter"/>
> 
> 
> 
> 
> On Tue, May 27, 2014 at 6:36 PM, Justin Richer <jricher at mit.edu> wrote:
> No, there isn’t one at this time, but that’s not a bad idea to have something like that in the future.
> 
> In the absence of that, you just need to set up an OAuth 2 resource server from Spring Security OAuth. You can find examples within that project — the bean creates a filter that you then add to your “http” block. Then wire in the “token services” of that filter bean with a copy of the “IntrospectingTokenServices” class, configured to talk to your authorization server. This will effectively act as a stand-in for the usual database-backed token services. From that point, it’s pretty much just using Spring Security and Spring Security OAuth like normal.
> 
> The documentation on the wiki page really should have the most comprehensive information:
> 
> https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/wiki/Token-Introspecting-Client-Config
> 
>  — Justin
> 
> On May 27, 2014, at 6:27 PM, Duc Nguyen <nguyen.d.duc at gmail.com> wrote:
> 
> > Hello, is there an example (similar to simple-web-app) of how to use Token Introspection? I've read the source & documentation and been at this the last couple of days so any help would be greatly appreciated. Thanks, -Duc
> > _______________________________________________
> > mitreid-connect mailing list
> > mitreid-connect at mit.edu
> > http://mailman.mit.edu/mailman/listinfo/mitreid-connect
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20140528/d27d0f2c/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20140528/d27d0f2c/attachment-0001.bin