This post is a technical note on using security within the Tivoli Federated Identity Manager Security Token Service. It will be of interest to Tivoli Federated Identity Manager customers using the TFIM STS as a service for identity mediation and token exchange.
I had an interesting enquiry about using the Tivoli Federated Identity Manager Security Token Service (TFIM STS) as a service, and only allowing certain STS clients in the enterprise to be allowed to execute "their own" trust chain, and not others. The default role-based security in the ITFIM Runtime application is quite coarse-grained. You either get access to the call the STS or not, there is no per-chain granularity.
With thanks to Craig Forster for the idea, I have developed a solution to this problem.
The solution is to include a new custom STS module at the very beginning of the chain(s) for you which want to restrict access. This module operates in authorize mode, and has configuration to define who may or may not access the chain based on their WebSphere login credential. There is a "default authorization policy" radio button group to allow access to everyone or implement a default-allow or default-deny policy, and in the latter two cases you can provide a list of users which are either explicitly denied, or explicitly allowed respectively.
For example, the configuration with a default-deny policy that allows ONLY the user called localhost:389/shane (as identified by the WebSphere security principal name) looks like this:
I have provided the example module, fully compiled and with source code (tested on TFIM 6.2), here. It is not supported code, however it contains nothing proprietary that you couldn't do yourself, so I've included source code for you to use without warranty. For information on building this code, please read the developerworks tutorial: Developing a custom Java module.
To get the module running, these are the basic steps:
- Copy the com.tivoli.am.fim.demo.callerazn_1.0.0.jar to /opt/IBM/FIM/plugins
- Use the TFIM Console to Domain Management -> Runtime Node Management -> Publish Plugins
- Reload configurations when prompted
- Additionally, either refresh the management service from the Domains panel, or just restart the WebSphere where the management service is running
- Use the TFIM console to create a new module instance - the new type com.tivoli.am.fim.demo.callerazn.CallerAznSTSModule should now be in the list of module types
- Modify the chain you want to protect to include this module as the first in the chain, and configure it's properties as you wish for the policy you want to enforce
- On the WebSphere Security -> Secure administration, applications, and infrastructure -> Web Security -> General Settings, the checkbox Use available authentication data when an unprotected URI is accessed should be checked
- (Optional) In Enterprise Applications -> ITFIM Runtime -> Security role to user/group mapping, change TrustClientInternalRole to something other than Everyone
Your trust client must now provide authentication data to WebSphere. This could be directly to WebSphere via basic-authentication, or it might be via another SSO mechanism such as Tivoli Access Manager WebSEAL with TAI++ to WebSphere (then your trust client can authenticate however it likes to WebSEAL). In any case, you can use the WebSphere tracing facility on the trace string com.tivoli.am.fim.demo.*=all to see what the module is discovering about the userid calling trust client.
This exercise demonstrates just how flexible and extensible the interface to the TFIM STS is, and how even fine-grained security requirements can be catered for in it's pluggable model. You could easily extend this demonstration code to perform more complex authorization decisions based on the user's groups, or external sources.