Introduction to ITFIM

IBM Tivoli Federated Identity Manager® (ITFIM) is a software solution that uses open security standards to provide federated single sign-on (FSSO), an implementation of the WS-Trust specification and Web Services Security Management (WSSM). This article addresses scripted configuration of the ITFIM for FSSO. WS-Trust, Key Management, and WSSM will be the subject of a subsequent articles.

Ok, but what exactly is ITFIM? Why is it useful?

ITFIM is a group of web applications that work together to provide such functions as federated single sign-on, token exchange, and key management. One of the core concepts in Federated Identity Management involves exchanging security tokens of a given input token type for an output token type. As part of this process arbitrary attributes can also get mapped into the output token as required to federate the identity information. WSSM provides this feature and other ITFIM capabilities to web services, extending WebSphere's WS-Security infrastructure to allow arbitrary web services to use the Tivoli Access Manager authentication and authorization engine already integrated with ITFIM.

What is Federated Single Sign-On (FSSO)?

FSSO allows two or more autonomous organizations to form a trust relationship such that one organization can securely verify the identity of its users to the other organizations. In the simplest scenario, there are just two entities. One will have the role of Identity Provider (IP); the other will be the Service Provider (SP). The IP maintains the identity data for its customers or users and wants to allow them access to the services of the SP. In all single sign-on scenarios, the end-user logs in to her IP, which securely asserts the validity of the user's identity to the SP. If the SP accepts this assertion, then the end-user gets logged into the SP and receives access to that organization's services. Notice that the end-user has had to log in only once. These groups of organizations, interconnected by trust relationships, go by different terminology depending on the protocol. For example, the Liberty protocol refers to these groups as circles of trust. ITFIM uses the term federation.

What are the benefits of FSSO?

FSSO saves the IP and SP the time and expense that would be required to maintain distinct sets of redundant data allowing them to focus on their core areas of interest or competence. For the end-user FSSO means that they need only remember one username and password to have access to all of the services available through the federation.

FSSO based on open standards allows for vendor-neutral solutions. As long as different vendors have implemented the single sign-on protocols according to the specifications, then their software will interoperate with that of other vendors.

How does ITFIM Management and Configuration Work?

ITFIM Management relies on a client-server model in which a management client, such as the ITFIM Management Console or a custom management script, sends management requests to a given WebSphere Application Server or Deployment Manager running the ITFIM Management Service application. The ITFIM Management Service processes the requests and modifies the configuration accordingly. In addition to centralizing all configuration tasks under one component, this model allows one client to manage multiple ITFIM installations.

Organization of ITFIM Configuration: FIM Domains

ITFIM configuration is organized around the concept of FIM Domains. On the management client-side, a FIM Domain encapsulates information used to identify the configuration on a given ITFIM management server. Such information includes the ITFIM Management Service machine hostname and SOAP port. If WAS global security is enabled on the machine, the client must supply the appropriate credentials or the server will reject any management requests. The FIM Domain's name on the client-side corresponds to a location in the WebSphere configuration repository. This sub-directory contains all ITFIM configuration files, HTML response pages, and key stores for each FIM Domain. The sub-directory's name is always the same name as the FIM Domain. All ITFIM management clients must supply this name in order to manage the configuration in these locations. The FIM Domain names must be unique within a given ITFIM Management Service host.

Essential Tool: Middle Management API

The ITFIM Management Console and all other management clients, including the scripts which this article addresses use a client-side API called the middle management API. Through this API, a client can control all configurable aspects of ITFIM. This article will address best-practice usage of the middle management API in subsequent sections.

Getting started with ITFIM Scripting: Jython and wsadmin

This article focuses on the use of the middle management API in Jython scripts to configure and manage ITFIM. Jython is the 100% pure Java implementation of the Python programming language. Python is a powerful scripting language with many useful traits and features. It has a very intuitive and simple syntax that fosters rapid learning of the language basics for beginners. Experienced Python programmers report that solving complicated problems using Python programs often takes many fewer lines of code than solving the same problems in languages such as C and Java, which often have significant syntactic overhead or other impediments to productivity. Python is an interpreted language with C-based interpreters available for multiple platforms. Jython, on the other hand, is a Python interpreter written in 100% Java, making it possible to execute Python language scripts on a Java Virtual Machine. One of the other distinct benefits of Jython is that it allows the use of any Java API within a Python language script. Because Jython interprets the scripts and executes dynamically generated Java byte-codes on the virtual machine, using Jython eliminates the code, compile, run cycle which writing pure Java code mandates.

WebSphere's command line administration tool wsadmin contains an embedded Jython interpreter and makes it possible to perform all administration tasks using Jython scripts. ITFIM capitalizes on this capability to provide the same scriptability to ITFIM administrators. Python and Jython tutorials are beyond the scope of this article. However, the internet abounds with resources of that type [provide some links?]. Also, for information on Jython or Python, please refer to www.python.org or www.jython.org respectively.

Prerequisites

This article presupposes that you have installed ITFIM correctly and have both the ITFIM Management Service and ITFIM Management Console installed and ready to use. You should install ITFIM Fixpack 1, if available, as well. From this starting point, you must create a FIM Domain as it is the first step toward doing anything useful with ITFIM. Though you can use the ITFIM Management Console to perform this and most other configuration tasks, this article will instruct you how to write Jython scripts for these tasks.

To ease your use of wsadmin, you should use one of the scripts included in the script source code bundle. These scripts set up the execution environment and classpath, enabling wsadmin to access ITFIM jar files while hiding these details from the user. The bundle contains a MS-DOS batch file and a Unix shell script. These files are equivalent in their purpose and function. You can see what these scripts do by referring to Listing 1 below. The file in the listing is FIMConsole.sh. The MS-DOS batch file version is called FIMConsole.bat.

				
#!/bin/sh


# From FIM Build
#You will need to set up this directory
#FIM_LIB=/root/script_testing/fim_lib
CONSOLE_EXPORT=${FIM_LIB}/itfim-fimconsole-export.jar
METADATA=${FIM_LIB}/itfim-metadata.jar
LOG_MSG=${FIM_LIB}/itfim-svc.jar
COMMON=${FIM_LIB}/itfim-common.jar
MIDMGR=${FIM_LIB}/itfim-midmgr.jar
MGMT_INTF=${FIM_LIB}/itfim-mgmt-intf.jar
RTE_CONF=${FIM_LIB}/itfim-rteconf.jar
LIBERTY_SCHEMA=${FIM_LIB}/itfim-liberty_schema.jar
XSS4J_DSIG=${FIM_LIB}/xss4j-dsig.jar
JLOG=${FIM_LIB}/jlog.jar

# From WebSphere
WEB_SPHERE_HOME=/opt/IBM/WebSphere/AppServer

WSADMIN=${WEB_SPHERE_HOME}/bin/wsadmin.sh


FIMCLASSPATH=${RTE_CONF}:${LOG_MSG}:${COMMON}:${MGMT_INTF}:${CONSOLE_EXPORT}
FIMCLASSPATH=${FIMCLASSPATH}:${METADATA}:${MIDMGR}:${JLOG}:${CMDLINE}
FIMCLASSPATH=${FIMCLASSPATH}:${LIBERTY_SCHEMA}:${XSS4J_DSIG}

SCRIPT_NAME=$1
shift;
echo "Enter user name: "
read USER
echo "Enter password: "
read PASSWD

${WSADMIN} -lang jython -user ${USER} -password ${PASSWD} -wsadmin_classpath ${FIMCLASSPATH} -f "${SCRIPT_NAME}" $@

Back to top

Anatomy of a Jython Script: Configuring SAML 1.0 FSSO Example

This section discusses several excerpts from a fairly simple Jython script, in order to point out the notable features of a script including the import statements, a function definition, and a main block. A subsequent section will demonstrate and discuss in more detail the use of middle management API objects.

				
#Jython import statements
#There are two ways to import code modules in Jython
#The first method preserves the namespace of the imported module
#For example, "import sys" below implies that when we want to reference
#methods or attributes in the sys module, we must preface such
#references with the prefix "sys."

import sys, saml_utils, fed_utils, create_domain

#The second method imports the items into the global namespace
#So using the example below: "from fed_utils import FIM_TRUE, FIM_FALSE"
#We can now reference FIM_TRUE and FIM_FALSE without prefixing "fed_utils."

from fed_utils import FIM_TRUE, FIM_FALSE

#These classes come from Java language packages, which we will import and use
#interchangeably with Jython language modules

from com.tivoli.am.fim.middlemanager.ssps import FederationManager
from com.tivoli.am.fim.middlemanager.tokenservice import SecurityTokenManager

				
#Jython function definition
#Notice Jython strictly enforces tabbing to maintain its block structure
#Jython is a weakly-typed language, so you'll notice all variables and arguments
#are named with no reference as to their intended type
#Objects from Java (a strongly-typed language) get automatically coerced 
#to Jython types

########
# get_ip_cfg
#
# Creates a SAMLIdentityProviderConfiguration object using the 
# utility functions from saml_utils
########
def get_ip_cfg(is_partner, display_name):	
	keystore="DefaultKeyStore"
	keyname="testkey"
	base_endpoint="https://ip.example.com/FIM/sps"
	protocol_id="https://ip.example.com" 
	issuer=protocol_id
	assertion_keystore_alias="%s_%s"%(keystore, keyname)
	map_rule_path="ip_saml.xsl"
	cfg = saml_utils.create_saml_ip_cfg(is_partner, display_name, keystore, keyname,
					    base_endpoint, protocol_id, issuer, 
					    assertion_keystore_alias, map_rule_path)
	return cfg					    

				
#Below is the Jython equivalent of a main() method from C or Java
if __name__ == "main":
	
	# Checks for the correct number of command-line arguments
	if len(sys.argv) < 5:
		print_usage()
		raise SystemExit

	# Retrieves the command-line arguments
	host = sys.argv[0]
	port = sys.argv[1]
	cluster = sys.argv[2]
	domain_name = sys.argv[3]
	was_sec_props_file = sys.argv[4]
	
	# Gets an instance of FIMDomain, using a Jython module also distributed
	# with this file
	domain = create_domain.get_domain_instance(host, port, cluster, domain_name, was_sec_props_file)
	prepare_feds_map()
	
	# Gets instances of the appropriate Midmgr Manager objects
	fed_mgr = FederationManager.getInstance("configure_saml", domain)
	sec_tok_mgr = SecurityTokenManager.getInstance("configure_saml", domain)
	
	#Creates the federations and partners
	fed_utils.create_feds(prepare_feds_map(), fed_mgr, sec_tok_mgr)

Back to top

Creating FIM Domains

When creating a FIM Domain, you will use the following classes from the middle manager API: FIMDomain, WASSecurityInfo (if WAS global security is enabled), and RuntimeNodesManager. The FIMDomain classes encapsulates the data that constitutes a FIMDomain including among other things: the domain's name, management service host, SOAP port, and any WAS security settings. WASSecurityInfo does exactly what it is named for: encapsulating WebSphere global security settings. RuntimeNodesManager is a client-side management class that performs such tasks as creating FIM Domains, deploying the runtime, restarting the WAS environment, to name a few. You must configure and deploy the ITFIM Runtime to execute FSSO operations. These operations are rare, but easily scriptable using the RuntimeNodesManager class. Treat these two steps as an exercise for the reader.

Use the create_domain.py script to create a FIM domain. You will need to pass in the following command-line arguments:

• management host
• management port
• was cluster name
• FIM domain name
• security properties file

The security properties file is a java properties file containing WebSphere administration user credentials. If you intend to run your configuration scripts with WebSphere Global Security enabled, you must have this properties file available. All script examples assume that WebSphere Global Security is enabled. Though actual contents for your particular situation might vary slightly, the security properties file will have contents similar to the following example:

				
AdminUser=root
AdminPasswd=passw0rd
TrustedKeystorePath=/temp/DummyServerTrustFile.jks
TrustedKeystorePasswd=WebAS

To create a domain using the provided script example, you may use a command similar to the one given in Listing 6.

				
./FIMConsole.sh create_domain.py host 8881 server1 test_domain2 was_sec_props.properties

The command line arguments have the following meanings:

#host = DNS name of the machine running the ITFIM Management Service
#8881 = SOAP port of the WebSphere instance with the ITFIM Management Service
#server1 = in a single server WebSphere environment, the cluster name will be the server name
#test_domain2 = the name of the ITFIM domain to create
#was_sec_props.properties = the path to the WebSphere global security properties file

Nitty Gritty: How the Create Domain Script Example Works

The main block processes the command line arguments then calls the create_domain function.

				
if __name__ == "main":

	if(len(sys.argv) < 5):
		print "Required args: [host] [port] [cluster_name] [domain] [was_security_properties_file]"
		raise SystemExit
		
	host = sys.argv[0]
	port = sys.argv[1]
	cluster_name = sys.argv[2]
	domain = sys.argv[3]
	props_file = sys.argv[4]
	
	create_domain(host, port, cluster_name, domain, props_file)	
	raise SystemExit

The create_domain function uses get_domain_instance() in conjunction with the RuntimeNodesManager object to create the FIM domain on the FIM management server.

				
#######
# create_domain
#
# Gets an instance of a FIMDomain object and uses it to create the domain
# on the server
#
########
def create_domain(host, port, cluster, domain_name, was_security_prop_file=None):	
	domain = get_domain_instance(host, port, cluster, domain_name, was_security_prop_file)
	
	## The middle manager *Manager objects are instances retrievable by
	## a given name.  For this example, I have arbitrarily chosen
	## "CreateDomainScript".  You may choose whatever you like for your
	## own scripts.
	
	rtMgr = RuntimeNodesManager.getInstance("CreateDomainScript", domain)
	rtMgr.createDomain(domain)
	return domain

The get_domain_instance function can be re-used by other scripts to obtain instances of the FIMDomain class. Other examples included with this article re-use this function to avoid code duplication. See Listing 4 for an example of such re-use.

				
#######
# get_domain_instance
#
# Creates an instance of the FIMDomain object using the given parameters
# notice the was_security_prop_file argument in the function signature is
# assigned to None (the Jython equivalent of Java's null).  Jython provides 
# assignment in the function signature to allow for default values.  When
# a user invokes this function, she can do so without providing that argument
# at all and it will automatically receive the value None.
#
########
def get_domain_instance(host, port, cluster, domain_name, was_security_prop_file=None):
	domain = FIMDomain(domain_name, host, port, cluster)
	if(was_security_prop_file != None):
		ws_info = get_was_security_object(was_security_prop_file)
		if ws_info != None:
			domain.setWasSecurityInfo(ws_info)
	return domain

The function get_was_security_object returns an instance of WASSecurityInfo created from a Java properties file.

				
##########
# get_was_security_object
#
# Takes the name of a Java properties file and loads it into 
# a Jython dictionary, equivalent to a hashtable in other languages.
# The function uses the values in this table to create WASSecurityInfo object.
##########
def get_was_security_object(propsFileName):
	wsSec = WASSecurityInfo()
	propsFile = open(propsFileName, 'r')
	props = {}
	for line in propsFile.readlines():
		(key,val) = String.split(line,"=")
		props[key.strip()] = val.strip()
	
	propsFile.close()
	for key in required_keys:
		if not props.has_key(key):
			return None

	wsSec.setAdminUser(props[admin_user])
	wsSec.setAdminPasswd(props[admin_pwd])
	wsSec.setTrustedKeystorePath(props[trusted_keystore_path])
	wsSec.setTrustedKeystorePasswd(props[trusted_keystore_pwd])
	return wsSec

Back to top

Creating Federations

Web single sign-on (SSO) occurs between two organizations or entities joined in a particular trust relationship, which in ITFIM parlance is called a federation; in a federation there is always one entity called the self and at least one partner. In order to configure ITFIM for web single sign-on, you must create a federation and add a corresponding partner to it. A Federation or Partner object in the middle manager API is simply a wrapper around SSO protocol-specific configuration data. The Federation object contains the self-configuration data, while a Partner object contains partner configuration.

FederationManager Overview

The FederationManager class performs management operations relating to federations, including creating, listing, and removing federations.

Creating a federation involves the following steps: create and populate an appropriate ConfigurationParameters object, obtain an instance of FederationManager and call createFederation and commitSession against the instance.

• ConfigurationParameters Overview

  ConfigurationParameters is the abstract base class for SSO protocol-specific configuration data and implements the attributes and behavior common to all protocols. ITFIM supports the following SSO protocols: Liberty 1.1, Liberty 1.2, SAML 1.0, and WS-Federation 1.1. The roles in a federation are identity provider and service provider. There are ConfigurationParameters subclasses such as LibertyIdentityProviderConfiguration and SAMLServiceProviderConfiguration among others that correspond to protocol and role of the organization involved in the federation.

• MapInstanceProperties Overview

  One of the key steps in ITFIM web single sign-on is a token translation step, in which an incoming security token type from a partner gets exchanged for an outgoing token type. ITFIM maps certain fields and attributes from the incoming token into the outgoing token as required by the federation partners involved. This mapping step is described by an XSLT transformation. All federations must specify an XSLT transformation rule describing how to map the incoming token type to an outgoing token type. ITFIM ships with several example XSLT rules that perform the bare minimum mapping needed to complete a single sign-on operation for each protocol. The MapInstanceProperties class helps to manage the configuration properties for the mapping rule.

• WS-Federation

  WS-Federation is one of ITFIM's supported single sign-on protocols. ITFIM supports configuration of the fields required by the WS-Federation passive client profile using the following classes: WSFederationConfigurationParameters, WSFederationIdentityProviderConfiguration and WSFederationServiceProviderConfiguration. The methods and fields provided through these classes are well-documented in the middle manager API javadoc. A subsequent section will demonstrate how to use these classes in a configuration script.

• SAML 1.0

  SAML 1.0 is another of ITFIM's supported single sign-on protocols. ITFIM supports configuration of the fields required by the SAML 1.0 single sign-on specification using the following classes: SAMLConfigurationParameters, SAMLIdentityProviderConfiguration and SAMLServiceProviderConfiguration. The methods and fields provided through these classes are well-documented in the middle manager API javadoc. A subsequent section will demonstrate how to use these classes in a configuration script.

• Liberty 1.1 and Liberty 1.2

  ITFIM supports both Liberty 1.1 and Liberty 1.2 protocols. ITFIM supports configuration of the fields required by the Liberty specification using the following classes: LibertyConfigurationParameters, LibertyIdentityProviderConfiguration, LibertyServiceProviderConfiguration, Liberty1_2IdentityProviderConfiguration, and Liberty1_2ServiceProviderConfiguration. The methods and fields provided through these classes are well-documented in the middle manager API javadoc. A subsequent section will demonstrate how to use these classes in a configuration script.

Adding Partners

Once you have successfully created a federation, you must add a partner to it in order for single sign-on to work correctly. After a createFederation operation, you will have a reference to both a Federation and a FederationManager object. To add a partner to the federation, you need only create the appropriate ConfigurationParameters object for the partner, instantiate a partner object, call addPartner against the Federation object and commitSession against the FederationManager. The following script examples will demonstrate how to add partners for each of the supported protocols. Note that the Liberty specification defines a schema for Liberty metadata, an XML document with all the relevant information about the Liberty entity. So there are actually two ways to script adding a partner to a Liberty federation, which the scripts will demonstrate.

Adding partners to a federation works the same way regardless of the role or protocol in use. The client must have an appropriate instance of a ConfigurationParameters subclass. For Liberty, there are two ways to obtain such an instance, while for the other protocols there is only one. Liberty has published a metadata schema that Liberty implementations can use to export in a self-contained XML document all of the relevant information about a Liberty entity, including web endpoints, organization name and contact information, and public certificates for signature validation. Partners in a Liberty federation can exchange these metadata documents to facilitate exchange of information vital to establishing the trust relationship. For example, adding a Liberty partner to a Federation in ITFIM using a metadata file will create an ITFIM Partner configuration using the information contained in the file. Subsequent sections will illustrate how to use ITFIM's Liberty Metadata API to generate LibertyConfigurationParameters objects from Liberty metadata XML files.

Federation Creation/Partner Adding Scripts

Subsequent sections contain script examples that create federations and add partners for each single sign-on protocol. For each protocol, the self can be either the identity provider or service provider; there will be scripts to demonstrate both.

The fed_utils.py script contains several commonly used methods for creating and deleting federations. The FSSO protocol-specific scripts, configure_liberty.py, configure_saml.py, and configure_wsfed.py demonstrate how to use the necessary APIs to configure federations and their partners. You may use them as a guide when writing your own scripts. See Listing 6 for a detailed explanation of the command line arguments.

				

#To run the configure_liberty example (note: the 1_2 argument tells the script to 
#create Liberty 1.2 federations; 1_1 would create Liberty 1.1 federations):
./FIMConsole.sh configure_liberty.py host 8881 server1 test_domain2 was_sec_props.properties 1_2

#To run the configure_saml example:
./FIMConsole.sh configure_saml.py host 8881 server1 test_domain2 was_sec_props.properties

#To run the configure_wsfed example:
./FIMConsole.sh configure_wsfed.py host 8881 server1 test_domain2 was_sec_props.properties

Nitty Gritty: How to use the middle management API in Jython to configure federations -- SAML 1.0 Example

For purposes of code encapsulation the federation creation functions used in these examples are stored in a file called fed_utils.py. fed_utils provides several useful utility functions. However, for purposes of this discussion, the most important of them are create_feds and delete_feds. The configure_saml.py example as well as the other configuration scripts for the other protocols use the fed_utils functions to create federations.

				
########
# create_feds
#
# Takes a Jython dictionary object mapping a ConfigurationParameters object for 
# a federation to a Jython list of ConfigurationParameters objects for
# federation partners.  It uses the given FederationManager (fed_mgr) object
# and SecurityTokenManager (sec_tok_mgr) object to create the federation
# and its partners
#
########
def create_feds(fed_map, fed_mgr, sec_tok_mgr):
	fed_cfgs = fed_map.keys()
	for fed_cfg in fed_cfgs:
		print("Starting federation create: %s" % fed_cfg.getDisplayName())
		fed = fed_mgr.createFederation(fed_cfg, sec_tok_mgr)
		print("Finished federation create")		
		print("Beginning to add partners")
		partner_cfgs = fed_map[fed_cfg]
		for ptnr_cfg in partner_cfgs:
			print("Starting to add partner: %s"%ptnr_cfg.getDisplayName())
			ptnr = Partner(fed, ptnr_cfg) 			
			fed.addPartner(ptnr)
			ptnr.activate()
			print("Finished adding partner")
			
	
	print("Committing Changes")
	fed_mgr.commitSession()	
	print("Changes committed")

				
#########
# delete_feds
#
# Takes a Jython list of EntityGroup (federation) UUID's
# and removes all information associated with them from
# the server, using the provided FederationManager (fed_mgr)
# object and SecurityTokenManager (sec_tok_mgr) object.
##########
def delete_feds(fed_list, fed_mgr, sec_tok_mgr):	
	for fed_id in fed_list:
		fed = fed_mgr.getFederation(fed_id, sec_tok_mgr)
		print("Deleting %s -- %s"%(fed.getDisplayName(),fed_id))
		fed_mgr.deleteFederation(fed)
		
	fed_mgr.commitSession()

The saml_utils.py module contains utility functions for creating SAML 1.0 federations and partners. It contains two methods: one for creating identity provider configurations and one for service provider configurations. Because they are both quite similar in function and structure, this article will discuss just one of them. The code segment below creates all the web endpoints and required configuration items and XSLT mapping transformation to make the SAML 1.0 single sign-on protocol work correctly. Please consult your ITFIM documentation for more information on the use of XSLT mapping rules as that topic is beyond the scope of this article.

				
#####
# create_saml_ip_cfg
#
# Creates an instance of SAMLIdentityProviderConfiguration using the given
# arguments.  Notice that the last 6 arguments have been given default values
# which client code can override.
#####
def create_saml_ip_cfg(is_partner, display_name, keystore, keyname, base_endpoint, protocol_id, 
		issuer, assertion_keystore_alias, map_rule_path,
		soap_server_key_id="DefaultTrustedKeyStore_testwebseal", 
		artifact_cache_lifetime=30, allow_ibm_extension=FIM_FALSE, 
		soap_client_auth=FIM_FALSE, assertion_post_time=60, assertion_verify_sigs=FIM_TRUE):

	cfg = SAMLIdentityProviderConfiguration(is_partner)
	cfg.setDisplayName(display_name)
	cfg.setKeyIdentifier("%s_%s"%(keystore, keyname))		
	cfg.setProtocolId(protocol_id)
	cfg.setSuccinctId(fed_utils.create_succinct_id(protocol_id))
	endpt_prefix = fed_utils.create_base_endpoint_prefix(base_endpoint, display_name)
	cfg.setSignonEndpoint("%s/signon"%(endpt_prefix))
	cfg.setIPAssertionEndpoint("%s/soap"%(endpt_prefix))
	cfg.setAllowIBMProtocolExtension(allow_ibm_extension)
	if (is_partner):
		cfg.setSoapClientAuth(soap_client_auth)
		token_props = Properties()
		token_props.put(ip_token_key_keystore_alias, assertion_keystore_alias)
		token_props.put(ip_token_key_verify_sigs, Boolean(assertion_verify_sigs).toString())
		
	else:
		cfg.setArtifactCacheLifetime(artifact_cache_lifetime)			
		token_props = Properties()
		token_props.put(ip_token_key_issuer,issuer)
		#Note all items in the token_props map must be of String type
		#In Jython, backquoting a reference converts the item to its string 
		#representation
		token_props.put(ip_token_key_posttime_valid, `assertion_post_time`)
		cfg.setTokenInstanceProperties(token_props)
		rule = fed_utils.read_file_to_string(map_rule_path)
		map_props = MapInstanceProperties()
		map_props.addMappingRule(rule)
		cfg.setMapInstanceProperties(map_props.getMgmtMap(cfg))
	
	return cfg

Back to top

Conclusion

Using the script examples included in this article, you are now prepared to set up an ITFIM scripting environment and to configure ITFIM for federated single sign-on. Following the examples noted in this article, you will have configured your environment for SAML 1.0 federated single sign-on (FSSO) as either the identity provider or service provider. You will then be able to complete single sign-on operations with an appropriate partner. Using the other examples in the downloadable script-bundle included with this article, you will similarly be able to configure federations to use the WS-Federation and Liberty protocols. Future installments will detail how to configure ITFIM for stand alone WS-Trust operations, key management, and WSSM.

Back to top

Download

Information about download methods

Resources

• www.python.org is the definitive source for information related to the Python language
  
  
• www.jython.org is the definitive source for information related to Jython, the java-based Python variant
  
  
• Charming Jython (developerWorks, May 2003) provides a useful introduction to Jython programming
  
  
• Introduction to Jython, Part 1 (developerWorks, April 2004) provides a technical introduction to Jython
  
  
• Introduction to Jython, Part 2 (developerWorks, April 2004) provides an in-depth look at Jython; topics discussed include using Jython for the following: object-oriented programming, debugging, manipulating strings, and working with files
  
  
• From black boxes to enterprises, Part 1: Management, JMX 1.1 style (developerWorks, September 2002) describes the technology that provides the foundation for ITFIM scripting, useful only as a background reference
  
  
• WS-Trust is a web-services specification describing a means for exchanging a security token of one type for that of another type.
  
  
• WS-Federation describes how to perform federated single sign-on, independent of the security credentials used
  
  
• Project Liberty is a collection of specifications describing various identity federation operations, including federated single sign-on among others
  
  
• SAML (Security Assertion Markup Language) is a set of schemas and specifications for securely asserting digital identity information. Included in this set is a specification for federated single sign-on
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Introduction to ITFIM
• Anatomy of a Jython Script: Configuring SAML 1.0 FSSO Example
• Creating FIM Domains
• Creating Federations
• Conclusion
• Download
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

Dig deeper into Tivoli on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers