+

Search Tips   |   Advanced Search

Manage self-issue SAML token configuration using wsadmin commands

The SAMLIssuerConfig.properties file usage is deprecated in WebSphere Application Server Version 8. We can use the listSAMLIssuerConfig and updateSAMLIssuerConfig wsadmin command tasks to read and modify the SAMLIssuerConfig.properties cell level and server level configuration files. Starting with WebSphere Application Server Version 8, you should use the console or the setSAMLIssuerConfigInBinding command task to specify a self-issued SAML token's configuration as custom properties in the requester's outbound configuration in the general bindings or in the application-specific bindings. Do not use server level and cell level SAMLIssuerConfig.properties file.

The product provides an alternate way to specify a self-issued SAML token configuration in policy set bindings. Migrate self-issued SAML token configuration data from the SAMLIssuerConfig.properties file to the bindings. Specifying configuration data for creating self-issued SAML tokens in general bindings or application-specific bindings provides management flexibility to specify the configuration at a finer grained scope, in addition to the cell level and the server level. For example we can configure a specific SAML token issuer for a particular web service application, for an arbitrary group of applications, or for a web service application in a security domain.

Avoid trouble: Self-issued SAML token configuration data defined in the bindings takes precedence over data defined in the server level or the cell level SAMLIssuerConfig.properties file, in that order. When a self-issued SAML token configuration data is defined in an attached policy set bindings, the Web services security runtime environment will neglect the SAMLIssuerConfig.properties files, both at the server level and at the cell level. So it is important that when you migrate from the SAMLIssuerConfig.properties file to the bindings, migrate all the required properties.gotcha

Two command tasks are available to manage the SAMLIssuerConfig.properties file-based SAML issuer configuration. This file can be located at the cell level and the server level. These two tasks are:

  1. Run wsadmin task in the interactive mode. The following Jython script illustrates how to run wsadmin task in the interactive mode.

      AdminTask.listSAMLIssuerConfig('[-interactive]')

    To select the server level SAML issuer configuration, the serverName and nodeName parameters are required. If these parameters are missing, then the command task lists the cell level SAML issuer configuration.

  2. Use the listSAMLIssuerConfig command task to display the server level SAML issuer configuration.

      AdminTask.listSAMLIssuerConfig('[-nodeName Node01 -serverName server1]')

    We need the "monitor" or above administrative role privilege to execute the listSAMLIssuerConfig command.

  3. Use the updateSAMLIssuerConfig command task to update the server level or cell level SAML issuer configuration.

      AdminTask.updateSAMLIssuerConfig('[-IssuerURI My_Issuer -TimeToLiveMilliseconds 3600000 -KeyStoreRef "name=myKeyStore managementScope=(cell):Node01Cell:(node):Node01" -KeyAlias samlissuer -KeyName "CN=SAMLIssuer, O=Acme, C=US" -KeyPassword ***** -TrustStoreRef "name=myKeyStore managementScope=(cell):Node01Cell:(node):Node01 "]')

    If the serverName and nodeName parameters are not specified, then the task updates the cell level SAML issuer configuration.

    We need the "administrator" administrative role privilege to execute the updateSAMLIssuerConfig command.


Results

We have created command scripts to automate the process of updating the cell level or the server level SAMLIssuerConfig.properties files, or you have created self-issued SAML token configuration data as custom properties in the requester's outbound configuration in the general bindings or in the application-specific bindings.


Example

The following example illustrates how to add or modify self-issued SAML token configuration data in the application-specific bindings:

The following example illustrates how to modify the general bindings:

When specifying the application bindings, bindingLocation is a required parameter and can be supplied as a properties object. The property names are application and attachmentId. When specifying the general bindings, bindingLocation, which can be null or have empty properties, is required. Additionally, bindingScope is required if the scope is not global. Use the bindingName parameter to identify the binding location. For more information about bindingLocation, bindingScope, and domainName, refer to the setBinding or getBinding command tasks documentation.

To remove SAML issuer configuration custom properties from the bindings, use the console or the setBinding command task.


Related tasks

  • Configure application-specific and system bindings
  • Start the wsadmin scripting client

  • SAML Issuer Config Properties