There are some updates with respect to the federation examples I posted in the last weeks.
- Sources have been moved from Google docs to the Apache CXF project
- The SAML security token had a lifetime of 5 minutes which has been increased to 20 minutes
- The Tomcat authenticator doesn't redirect if the security token is expired instead it blocks the incoming request
Sources have been moved from Google docs to the Apache CXF project
You can find the sources here. Right now, you have to check out the sources and build them on your own. This is fairly simple with Maven (mvn clean install).
The package names have changed. Please ensure to configure the new package name org.apache.cxf.fediz. ...
The STS of the CXF release 2.5.1 is used
If you have any questions please raise them at the Apache CXF mailing list.
The SAML security token had a lifetime of 5 minutes which has been increased to 20 minutes
If you deploy the previous Tomcat example you could test the application for 5 minutes. Further requests have been rejected because the security token lifetime is expired (Condition in SAML 2.0).
I made the following changes to the STS configuration to change the default lifetime which is fairly simple to do due to the usage of Spring.
<bean id="transportSamlTokenProvider" class="org.apache.cxf.sts.token.provider.SAMLTokenProvider">
<property name="attributeStatementProviders" ref="attributeStatementProvidersList" />
<property name="conditionsProvider" ref="conditionsProvider" />
</bean>
<bean id="conditionsProvider"
class="org.apache.cxf.sts.token.provider.DefaultConditionsProvider">
<property name="lifetime" value="1200" />
</bean>
If you don't configure the DefaultConditionsProvider the default lifetime is 5 minutes. You configure a different lifetime by setting a value in seconds for the property lifetime.
The Tomcat authenticator doesn't redirect if the security token is expired instead it blocked the incoming request
As mentioned in the previous section, the issued SAML token expires after 5 minutes and blocks any incoming request of this user. The lifetime of the HTTP session and the security token can be different in deployments due to different non functional requirements for the application and the security infrastructure. Thus, the application server (Relying Party) should transparently redirect the user to the IDP. Usually, the user still has got a session with the IDP and is not challenged to enter username and password. A new SAML token is issued and sent back to the application server which validates the token and updates the session.
This fix has been applied in revision r1222148 here.
New features will come in New Year :-)
Merry Christmas and Happy New Year!
Hi Oli, about the redirection back to the IDP for an expired SAML token -- what config file does the Relying Party read to determine the correct IDP to route the requestor back to? Also, will the redirection be done for other token problems besides it being expired?
ReplyDeleteI wonder how secure it is to redirect back to the IDP. I don't know the whole process, but if Bad Guy (who swiped a now-expired token off the wire and failed in reusing it) can hijack the real user's session with the IDP, he might be able to get a new token without reauthenticating.
Hi Glen
DeleteThe IDP url is configured for Tomcat in the attribute "issuerURL" of the Valve configuration (server.xml or context.xml).
The rediret is done either if the requestor has no authenticated session with the Relying Party or if the token is expired.
A bad guy must get into the possession of the session with the IDP. The communication between the browser and the IDP must be protected (HTTPS) as well as between the browser and the relying party to prevent that. The subject confirmation method of the issued SAML token is Bearer.
The relying party will detect replay attacks if a token is re-used.
The current IDP and tomcat plugin doesn't yet support Holder-Of-Key subject confirmation method which means that the browser must be in the possession of a client certificate which is verified by the relying party against the SAML token. That means that a bad guy must be in the possession of the certificate/private key and the SAML token.