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" />
<property name="lifetime" value="1200" />
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.