Running the Security Identity Propagation sample
To run the Security Identity Propagation sample,
you put each of the sample messages through the appropriate transport input
node on the main Security Identity Propagation message flows.
You can run the sample to learn what happens in the following situations:
- The input message from WebSphere MQ contains a user identity token in the
message MQMD header.
- The input message from WebSphere MQ contains a set of user identity credentials
in the message body.
- The input message from WebSphere MQ contains a request element that is used by the
Compute node in the main flow to set the mapped identity credentials.
The mapped identity credentials are based on the user identity token that is present in the
MQMD header of the input message.
- The input request message from HTTP contains a user identity and password token.
The user identity and password token are present in the HTTP Basic Authentication header.
For more information, see About the Security Identity
Propagation sample.
If you encounter any problems when you run the sample, see
Resolving problems when running samples
in the WebSphere Message Broker documentation.
Running the sample with a WebSphere MQ message that contains a user
identity token in the message MQMD header
The MQMD message header in WebSphere MQ messages provides the following
pieces of information to the security system in the broker:
- The "user name" string from the User id field.
- The "issued by" string from the Put application name field.
To run the sample with the WebSphere MQ message that contains a user
identity token in the MQMD header:
- In the Broker Development view,
expand the SecurityIdentitySampleFlowProject project. Expand the Flow Tests directory
and double-click Security_Identity_MQ_ID.mbtest
to open the file in the Test Client.
- Click Enqueue on the message flow test events toolbar.
Note that the XML message does not contain any elements in the message body.
- Expand Header in the Detailed Properties section.
Note that the Message Header selected is Send Identity.
If you switch to the Configuration tab in the
Test Client, and select MQ Message Header "Send Identity",
you can view the details of the header.
These details include mqmdUID
as the User id, and
Test Client as the
Put application name.
- On the Events tab,
click Send Message.
The message is put to the SECURITYIDFROMMQIN queue.
- Look at the results:
- Get the result message from the SECURITYIDFROMMQOUT queue.
- In the Test Client, click Dequeue.
- Click Get Message.
The output message is displayed under Message.
- You can see new elements under PropagatedIdentityReport,
which reports the propagated identity details
that were passed to the SecurityIdentityReportFlow message flow from the input message.
- Note that the reported identity in the output message is the user name mqmdUID.
Because there is no
field for the password in the MQMD, the Password
field is blank in the message.
IssuedBy is set to the arbitrary value HTTP because the broker does not set the HTTP UserAgent header property.
Running the sample with a WebSphere MQ message that contains identity credentials
in the message body
To overcome the restriction that the WebSphere MQ MQMD can provide only the
issuer and user identity token, an additional MQInput node is provided.
This node is configured to extract a full set of security credentials from
fields within the message body.
To run the sample with the WebSphere MQ message that contains a user identity token in
the message body:
- In the Broker Development view,
expand the SecurityIdentitySampleFlowProject project. Expand the Flow Tests directory
and double-click Security_Identity_MSG_ID.mbtest to open the file in the Test Client.
- Click Enqueue.
Note that the message contains elements in the Body.MessageIdentity folder,
which defines the following Identity credentials:
- Username: IdInMsg
- Password: PwdInMsg
- IssuedBy: InMsgIssuer
- Expand Header in the Detailed Properties section.
Note that the Message Header selected is Default Header.
If you switch to the Configuration tab in the Test Client, and select
MQ Message Header "Default Header",
you can view the details of the header. The User id and
Put application name are blank.
- On the Events tab,
click Send Message.
The message is put to the SECURITYIDFROMMSGIN queue.
- Look at the results:
- Get the result message from the SECURITYIDFROMMSGOUT queue.
- In the Test Client, click Dequeue.
- Click Get Message. The output
message is displayed under Message.
- You can see the body elements created in the SecurityIdentityReportFlow message flow
from the input message.
- Note that the reported identity in the output message matches the details in the
MessageIdentity elements from the input message.
The issuer is set to the arbitrary value HTTP because the issuer is not propagated.
Running the sample with a WebSphere MQ message that requests a mapped identity to be set
When working with WebSphere MQ messages that contain only the user name and issuer,
it is often necessary to invoke a federated identity mapping on the credentials.
The credentials can then be mapped into a form that is suitable for invoking a service request,
for example, that requires a username and password.
Typically, an external federated identity manager is invoked to perform this operation.
This sample provides a simple solution in which a Compute node is used to map the incoming identity,
so that the following security credentials are created:
- The token type is username and password.
- The username is created as "lowercase(received id)" + "@company.com".
- The password is created as
"p_" + "lowercase(received id)" + "year(current timestamp)".
To run the sample with the WebSphere MQ input message that contains a request to set
the mapped identity based on the username passed in the MQMD of the message:
- In the Broker Development view,
expand the SecurityIdentitySampleFlowProject project. Expand the Flow Tests directory
and double-click Security_Identity_Mapped.mbtest to open the file in the Test Client.
- Click Enqueue.
Note that the message contains the Body.MapIdentity element.
The presence of this element in the message causes the ESQL in the
SecurityIdentitySampleFlow message flow to set the mapped Identity credentials as described above.
- Expand Header in the Detailed Properties section.
Note that the Message Header selected is Send Identity.
If you switch to the Configuration tab in the Test Client, and select
MQ Message Header "Send Identity",
you can view the details of the header. These details include TESTUSER as the User id, and
BRKTSTCLNT as the Put application name.
- On the Events tab,
click Send Message.
The message is put to the SECURITYIDFROMMQIN queue.
- Look at the results:
-
Get the result message from the SECURITYIDFROMMQOUT queue:
- In the Test Client, click Dequeue
-
Click Get Message. The output message is displayed under Message.
You can see the body elements created in the SecurityIdentityReportFlow message flow
from the input message.
Note that the reported identity in the output message has been created
from the mapping of the username sent in the MQMD of the input message:
- Token: "testuser@company.com"
- Password: "p_testuser2011"
The issuer is set to the arbitrary value HTTP because the issuer is not propagated.
Running the sample with a HTTP request message
The HTTP transport allows for security credentials like user name and password to be
passed in the HTTP header.
A Java application has been provided, to run the sample with an
HTTP request message that contains a user identity and password token in the HTTP
Basic Authentication header.
The Java application enables you to submit the contents of a text file,
including a username and password, to the Sample Message Flow HTTP Input.
The sample program has the following arguments:
java BasicAuthHttpPost
<URLHost> <URLPort> <URLPathSuffix> <XML file>
[<UserId> <Password> ]
Where the arguments are:
- <URLHost> - Host name to send HTTP Request to, this is set to
localhost.
- <URLPort> - HTTP Service port, this is the Broker default of
7080.
- <URLPathSuffix> - HTTP URL suffix, this is
/Security/IdentityFromHttp.
- <XML file> - Path to the file containing the data to send as the
body of the HTTP request.
This file is Messages\Simple.xml because the sample message data file
Simple.xml is located in the same project as the
Java source in the Message package.
- <UserId> - Plain text user ID to send in the HTTP Request header.
- <Password> - Plain text password to send in the HTTP Request header.
To run the sample with a HTTP request message:
- In the WebSphere Message Broker Toolkit, switch to the Java perspective.
- In the Package Explorer view, expand the package
com.ibm.wmb.sample.httpClient by expanding the
SecurityIdentitySampleApplicationProject project.
- Right-click HttpPostFileWithBAuth.java
under com.ibm.wmb.sample.httpClient and select
Run As > Run Configurations to open the
Run Configurations wizard.
- Double-click Java Application in the left tree view
and select the configuration called HttpPostFileWithBAuth.
- In the Main tab, ensure Project is set to
SecurityIdentitySampleApplicationProject.
- Ensure that Main class is set to
com.ibm.wmb.sample.httpClient.HttpPostFileWithBAuth.
- Switch to the Arguments tab in the Run wizard,
and enter the following in Program Arguments:
On Windows:
localhost 7080 /Security/IdentityFromHttp
Messages\Simple.xml HttpUserName HttpPassword
On Linux or Unix:
localhost 7080 /Security/IdentityFromHttp
Messages/Simple.xml HttpUserName HttpPassword
- You have created the Run Configuration.
Start the application to send the HTTP request to the sample by clicking
Run.
Look at the results:
- The output of the HttpPostFileWithBAuth Java application is displayed in the
Console view. The Console
view displays the HTTP response received
or details the failure to send or receive.
- The HTTP response message displayed has elements
in the Body folder that were created in the SecurityIdentityReportFlow message flow.
- The reported identity in the output message is HttpUserName and HttpPassword.
These are the values that were passed as arguments to the test application and sent
in the HTTP request message header.
The presence of these values demonstrates that the identity was propagated through
the HTTP request from the broker.
Back to sample home