This thread will discuss the requirements, design etc for the functionality of WS-Federation/STS across domains.
What is the major use case?
We have solved the requirement of having a STS within a single security domain. The domain can be a single JBoss cluster or a single machine or within a subnet. Now if the security propagation has to happen across multiple domains, then we need to bring in WS-Fed.
What is needed to implement WS-Fed?
In my view, the following is the path to getting the use case implemented.
- Get sample ws-fed payload data.
- Enhance the PL parsers to include WS-Fed payload.
- Enhance the PL STS configuration to handle WS-Fed.
- Create a working demo that people can download and test.
What is the end date for this implementation?
July 25th, 2011.
After taking a good look at the spec, I agree with the main points you outlined. I also think we will need a web front-end for the STS to enable the retrieval of federation metadata via HTTPS. We also have to think how to configure the metadata the STS will expose.
While we are talking about HTTP, some scenarios use redirection to point the user to the STS in order to obtain a token. This probably means we will also need a web login form for the STS for redirected users to login and get their tokens using the web browser.
Also, many scenarios involves the claims needed to authorize access to a resource. That is, standard federation XML can include claims statements that must be verified and included in the assertions, such as groups, roles, e-mail, etc. While WS-Trust doesn't define a claim dialect, we have one for WS-Federation, the WS-Federation Passive Requestor Interoperability Profile (PRIP) which defines common types of claims that should be handled by federated STSs. I think we must support this too, which means the STS must act as some sort of identity provider or at least access the identity provider that can verify the claims.
I have determined that our configuration framework common to the sts and idp needs to be a little more smart and extendable, with the use of DB, ldap, metadata etc as identified here: http://community.jboss.org/thread/168336?tstart=0
At this time, I am very interested in seeing sts across domains/clusters.
I've recently contributed a federation plugin for Tomcat here:
whereas 80% is Tomcat agnostic (fediz-core) and 20% tomcat specific (custom Authenticator). I think this could be easily re-used within JBoss as it uses Tomcat also.
I've also contributed a mock idp/sts which is able to issue SAML tokens which contain claims (which is also standardized by OASIS) and such.
The IDP component is a very thin facade as most of the token issuance functionality is encasulated within the STS. Therefore, the STS can be re-used to secure the Web-Services communication also. In this case, the web application must request a new token (based on WS-SecurityPolicy) on behalf of the token issued during the web login.
More information are available here: