IBM Integration Bus, Version 9.0.0.8 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

See information about the latest product version

Identity

In IBM® Integration Bus, an identity is a security token that uniquely identifies an individual, or that provides a set of assertions that can be validated.

When a SecurityPEP node or a supported input node is configured with a security profile, the extracted identity is held in the broker as eight properties in the Properties folder of the message tree structure. These properties define two identities in the broker: source and mapped. For both the source and mapped identities, values are held for Type, Token, Password, and IssuedBy properties:

Diagram showing the eight identity properties.

The Identity token type property on the security-enabled input nodes can be set to a value of Transport Default, which causes the token type to be created from the default identity header or fields of the transport. For WebSphere® MQ, Transport Default provides an identity type of Username. For HTTP, Transport Default provides an identity type of Username and Password. The Identity token type property on the SecurityPEP node can be set to Current Token, which enables it to use the identity in the Properties folder fields instead of extracting a new identity from the message.

The following table shows the support that is provided (by the message flow security manager and external security providers) for the extraction of different types of security token. For information about the token types that are supported for identity propagation, see Identity and security token propagation.

Table 1. Support for security token types - token extraction
Token type (format)	Broker security manager support for token extraction	External security provider support
Username	Username tokens are supported for extraction by the following nodes: HTTPInput MQInput SCAInput SCAAsyncResponse SecurityPEP SOAPInput The token is obtained from one of the following transport headers: MQ From MQMD user ID HTTP From HTTP BasicAuth header containing only a username part SOAP From a WS-Security UsernameToken header. The policy set and binding (associated with the SOAP node) must define a username profile, and the wsse:UsernameToken must contain only a `wsse:Username` element. From the Kerberos subject in a WS-Security header. The policy set and binding (associated with the SOAP node) must define a Kerberos profile. From the HTTP BasicAuth header containing only a username part if no policy set is defined on the SOAP node. Alternatively, the token can be taken from any part of the message tree when the token location is specified (on the node) using an XPath expression or ESQL field path. The literal string value used by the broker (and which you can use to specify the token type in an ESQL or Java™ program) is `username`.	LDAP: Authorization WS-Trust V1.3 STS (including TFIM V6.2): Authentication Mapping Authorization Note: To prevent the use of a username token (rather than a username and password token) with these security providers, consider setting the Reject Empty Password security profile property to `TRUE`. The security manager then rejects a user name during authentication if the user name has an empty password token, and the user name is not authenticated with the external security provider.
Username and password or Username and RACF® PassTicket	Username and password tokens are supported for extraction by the following nodes: HTTPInput MQInput SCAInput SecurityPEP SCAAsyncResponse SOAPInput The token is obtained from one of the following transport headers: HTTP From HTTP BasicAuth header containing both a username and password part SOAP From a WS-Security UsernameToken header. The policy set and binding (associated with the SOAP node) must define a username profile and the wsse:UsernameToken must contain both `wsse:Username` and `wsse:Password` elements. From the HTTP BasicAuth header containing only a username part if no policy set is defined on the SOAP node Alternatively, the token can be obtained from any part of the message tree when the token location is specified (on the node) using an XPath expression or ESQL path. The password token can carry either a clear text password or a RACF PassTicket. If you are using a WS-Trust V1.3 STS (such as TFIM V6.2), you can use it to map (issue) or validate RACF PassTickets, by specifying the token type as `Username and password`. This support is available with security enabled input nodes and SecurityPEP nodes. The literal string value used by the broker (and which you can use to specify the token type in an ESQL or Java program) is `usernameAndPassword`.	LDAP: Authentication Authorization TFIM V6.1: Authentication Mapping Authorization WS-Trust V1.3 STS (including TFIM V6.2): Authentication Mapping Authorization IWA: Authentication
SAML assertion	SAML tokens are supported for extraction by the following nodes: SecurityPEP MQInput HTTPInput SCAInput SCAAsyncResponse SOAPInput The token is obtained from one of the following places: SOAP From a WS-Security header. The policy set and binding (associated with the SOAP node) must define a SAML profile. Any part of the message tree when the token location is specified using an XPath expression or ESQL path. The literal string value used by the broker (and which you can use to specify the token type in an ESQL or Java program) is `SAML`.	WS-Trust V1.3 STS (including TFIM V6.2): Authentication Mapping Authorization
Kerberos GSS v5 AP_REQ	Kerberos tickets are supported for processing by the message flow security manager from the SecurityPEP node. A WS-Security Kerberos token profile is supported by the following SOAP nodes, but in this case, the Kerberos Key Distribution Center is communicated with directly, and the properties folder is populated with a Username token representing the Kerberos subject: SOAPInput The token is obtained from any part of the message tree at a SecurityPEP node, if the token location is specified using an XPath expression or ESQL path. The literal string value used by the broker (and which you can use to specify the token type in an ESQL or Java program) is `kerberosTicket`.	WS-Trust V1.3 STS (including TFIM V6.2): Authentication Mapping Authorization
LTPA v2 token	LTPA tokens are supported for extraction by the following nodes: SecurityPEP SOAPInput The token is obtained from any part of the message tree at a SecurityPEP node, if the token location is specified using an XPath expression or ESQL path. The literal string value used by the broker (and which you can use to specify the token type in an ESQL or Java program) is `LTPA`.	WS-Trust V1.3 STS (including TFIM V6.2): Authentication Mapping Authorization
X.509 Certificate	X.509 tokens are supported for extraction by the following nodes: SecurityPEP MQInput HTTPInput SCAInput SCAAsyncResponse SOAPInput The token is obtained from one of the following places: SOAP From a WS-Security header. The policy set and binding (associated with the SOAP node) must define an X.509 profile. Any part of the message tree when the token location is specified using an XPath expression or ESQL path. The literal string value used by the broker (and which you can use to specify the token type in an ESQL or Java program) is `X.509`.	TFIM V6.1: Authentication Mapping Authorization. WS-Trust V1.3 STS (including TFIM V6.2): Authentication Mapping Authorization.
Universal WSSE token	Universal WSSE tokens are supported for extraction by the SecurityPEP node only. The token is obtained from any part of the message tree at a SecurityPEP node, if the token location is specified using an XPath expression or ESQL path. The literal string value used by the broker (and which you can use to specify the token type in an ESQL or Java program) is `UniversalWsse`.	WS-Trust V1.3 STS (including TFIM V6.2): Authentication Mapping Authorization.

The source identity is set by the SecurityPEP or input node only if a security profile is associated with the node. The information to complete these fields is typically found in the headers of a message but can also be located in the body (provided that the node has been configured with an ESQL Path or XPath reference for the various properties). If multiple identities are available (for example, if you are using message aggregation), the first identity is used. The token extraction is transport specific and can be performed only using transports that support the flow of identities. These transports are: Websphere MQ, HTTP(S), and SOAP. See MQInput node and HTTPInput node for more information.

You can modify the values in the properties (for example, from ESQL), but do not write to the IdentitySource* values. For example, you can create a custom identity mapping routine in ESQL or Java by using the IdentitySource* values to create custom IdentityMapped* values.

SAML and Universal WSSE tokens are stored in the Properties tree IdentitySourceToken or IdentityMappedToken field as a character bit stream. To access this data as a message tree, parse it into a suitable parser, such as XMLNSC:

-- Parse the mapped SAML2.0 token in the properties folder and set it in the message body
   CREATE LASTCHILD OF OutputRoot DOMAIN('XMLNSC') PARSE(InputRoot.Properties.IdentityMappedToken, 
   InputProperties.Encoding, InputProperties.CodedCharSetId);

To set either SAML or Universal WSSE tokens into the properties fields, you must obtain the bit stream of a tree; for example, by using the ESQL ASBITSTREAM function.

ap04010_.htm |

Last updated Friday, 21 July 2017