I will have multiple posts on this thread.
Integration with Containers in JBoss
Let us look at what the integration points are in the subsystems, from PicketLink perspective.
For Web Services, we recommend JAX-WS.
So, for EJB3 WS, we have a SAML2Handler. (https://docs.jboss.org/author/display/PLINK/SAML2Handler)
For POJO based WS, there is no container security kicking in. So we have a pair of handlers - one for authentication and one for authorization.
For Web based applications, if you need container integration, then you can write Tomcat Valves.
I would leave out JCA, JMS etc from discussion for now.
PicketLink also has a bunch of login modules that talk to an STS to get a SAML2 token. This is what we have used in integrating it to ejb3 etc
In the previous post, I talked about container integration points.
Now lets us look at the token itself.
The SAML assertion is very similar to a x509 certificate (but xml format).
In the current setup, we use a login module such as
to talk to an STS to get ourselves a SAML2 Token.
Now we can represent this as a Principal or Credential and pass it around the JBoss ecosystem. At each subsystem, the JAAS framework gets activated due to container security and we use the https://docs.jboss.org/author/display/PLINK/STSValidatingLoginModule
to either ask the STS to validate the token or perform local validation (signatures in the saml2 token + validity/expiration).
In my view, for your usecase, we need to tie in an additional attribute to the Principal apart from the saml2 token. The attribute will be the "domainName". So at each subsystem during validation, they can have local configuration to see which domains we accept. Then we perform local validation strategies on the principal and allow the call to proceed.
From the SAML specifications, it is done at the IDP. The IDP does a walkthrough with all SP to perform the logout. Even though it is available in the specs, GLO is very difficult to attain in practice. There is a major need to have a homogeneous ecosystem. Anytime there is an error in the lifecycle of a GLO action, it breaks.
In my view, for the user, when he logs out as GLO, we have to log him out from the first application he is using so the token does not get sent over in subsequent invocations. Since the token is typically shortlived (say 5 mins), the token should get cleaned up soon in the ecosystem.
After studying the picketlink code there are a few different approaches that can be taken here. They are all basically dependent on how the STS is used/deployed to issue and validate the SAML session token. Right now the PicketLinkSTS is a WS-Trust service and clients interact with it via a STSClient object. As a browser session jumps across standalone jboss servers and jboss clusters this introduces overhead by remotely calling the WS-Trust STS to issue and validate SAML session tokens each time. Plus requires the support and management of the STS. For performance it would be better to issue and validate tokens locally.
Option 1 - Leave the STS in a dedicated server. Potentially update the picketlink IDP web app to be the session authority (SA)
- Works nicely with the token reference algorithm
- Easy global logout as IDP/SA maintains session
- unnecessary overhead invoking a remote SA
- very similar to SAML SSO profile. Might be better off with existing SAML SSO profile and long lived SAML token set as cookie.
Option 2 - Deploy an STS to every JBoss server participating in the session
- Easy to implement the session reference algorithm as endpoint services and client already exist
- Easy to translate tokens if necessary
- need to update STSClient to make in-memory issue,renew,cancel,validate calls
- manage multiple deployments of picketlink-sts.war
Option 3 - Remove the STS and call the SecurityTokenProvider interfaces methods directly for a configured token provider
- In-memory calls available
- smallest memory footprint
- easiest to configure
- probably easiest to integrate with other JEE application servers as it removes the need to deploy and manage any war files
- Need to write new LoginModule to interface with token provider directly.
- Complexity of global logout if we want to clean up http sessions or other server resources.
I am leaning toward option 3 for a couple of reasons.
- A primary goal of mine to is remove the overhead of calling a remote STS constantly. This eliminates option 1 for the stateful token algorithm but still makes if available for the token reference algorithm for those that want its easy session management.
- Easy to configure and maintain. Most likely large enterprises will be using this feature for SSO across all there JBoss clusters. Easier the better.
- Third party vendor integration. Would like to be able to install this feature into WebSphere and WebLogic to hopefully get all the major JEE app servers working under a single SSO solution that does not require an STS for token translation. Simplicity is key. If successful I tackle world peace.
Implements the stateful and reference token algorithms in section 3 of the SAMLv2 Session Token Profile. When attempting to deploy to other application servers this class would be wrapped with a class that implements/extends the security api for the particular app server. A configuration property sets which types of tokens are supported and the keys used to decrypt and validate signatures.
wrapper to integrate SessionTokenManage functionality into JBoss and Tomcat.
Used in a login module stack. Issues a session token setting the authenticated identity, security realm and authorization roles. The SessionTokenLoginModule will not do any authentication or authorization on its own. It will merely set on the token the results of the other login modules on the stack. Configurations include which token types are supported and keys to encrypt and sign tokens.
Thoughts, insights? Solution sound reasonable?