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.
Has there been any further work on this topic? I have a need for this on my current project and would like to know if this work has continued or not.
Brian, we have not made progress here.
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: