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 integration node as eight properties in the Properties folder of the message tree structure. These properties define two identities in the integration node: source and mapped. For both the source and mapped identities, values are held for Type, Token, Password, and IssuedBy 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.
Token type (format) | Integration node security manager support for token extraction | External security provider support |
---|---|---|
Username | Username tokens are supported for extraction
by the following message flow nodes:
The token is obtained from one of the following transport
headers:
The literal string value used by the integration node (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):
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 message flow nodes:
The token is obtained from one of the following transport
headers:
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 integration node (and which you can use to specify the token type in an ESQL or Java program) is usernameAndPassword. |
LDAP:
|
SAML assertion | SAML tokens are supported for extraction by
the following message flow nodes:
The token is obtained from one of the following places:
The literal string value used by the integration node (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):
|
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:
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 integration node (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):
|
LTPA v2 token | LTPA tokens are supported for extraction by
the following nodes:
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 integration node (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):
|
X.509 Certificate | X.509 tokens are supported for extraction by
the following message flow nodes:
The token is obtained from one of the following places:
The literal string value used by the integration node (and which you can use to specify the token type in an ESQL or Java program) is X.509. |
TFIM V6.1:
|
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 integration node (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):
|
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.
-- 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.