UsernameToken Profile describes how a web service client application can supply a user name and an optional password in the message request that the web service server can use to authenticate the requester's identity.
Nonce is a token that contains a random value and is used to prevent replay attacks. A replay attack occurs when an attacker steals or intercepts a UsernameToken as it is used in legitimate transmissions and then fraudulently retransmits the UsernameToken in an attempt to gain access.
To help eliminate replay attacks, Nonce and Created elements are generated and included in the UsernameToken element of messages that the client sends to the server. The server checks the Nonce element against a cache of received nonces and verifies that the nonce does not match any of the nonces in its cache. The server can then reject messages that either have no Nonce element or have a Nonce element that has a matching Nonce element in its cache. Additionally, by requiring a Created element in the message and by comparing the server's current time against the time specified by the Created element in the message, the server can determine whether the difference between the two timestamps falls within an allowable window of time and then reject any messages with differences that exceed the window.
Nonce should be used in combination with Message level encryption or HTTPS for optimal protection.
At the time of this writing, additional information about the nonce could be found at in the following specification:
http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-UsernameTokenProfile.pdf
If the P6 EPPM Web Services application has been configured to use UsernameToken Profile for authentication, the server uses both a user name and a password to authenticate the message.
To configure the server to authenticate user credentials using Username Token Profile, perform the following steps:
- Launch the Administration Application.
- On the Configurations tab, set the Web Services/Security/Authentication/Mode setting to Username Token Profile.
- On the Configurations tab, set the Web Services/Security/Authentication/Username Token Profile settings for Nonce and Created as appropriate.
- Set Require Nonce to true to enable Nonce
- If you set Require Nonce to true, set the Nonce Cache Timeout to an appropriate time in seconds.
- If you set Require Nonce to true, set the Created/Require Created to true to require a timestamp.
The following example shows the syntax of the <UsernameToken> element:
<UsernameToken>
<Username>...</Username>
<Password Type="...">...</Password>
</UsernameToken>
Additionally, the Java example below shows how to use the UsernameToken.
Step one: Create the Username Token
For example, the following code snippet was extracted from the DemoOutInterceptor.java file that is included with the demo:
// Create the basic UsernameToken information with the specified username and password
UsernameToken unToken = WSSTokenUtils.createUsernameToken(wsuId, m_demoInfo.username, null, null, m_demoInfo.password.toCharArray());
// A timestamp that the server checks to see if this message has taken too long to reach the server
unToken.setCreatedDate(new Date());
// A token to help prevent replay attacks
// If a second message with the same Nonce data is sent within a configurable amount of time, it would be rejected by the server
unToken.setNonce(Base64.fromBase64(XMLUtils.randomName()));
sec.addUsernameToken(unToken);
// ....
Step two: Configure the CXF outgoing properties for including UsernameToken Information
For example, the following code snippet was extracted from the WSDemo.java file that is included with the demo:
if (m_demoInfo.authMode == USERNAME_TOKEN_MODE || m_demoInfo.authMode == SAML_MODE)
{
client.getEndpoint().getOutInterceptors().add(new SAAJOutInterceptor());
client.getEndpoint().getInInterceptors().add(new SAAJInInterceptor());
// To do UsernameToken or SAML, we use our own Interceptor
// This will also handle encryption, if enabled
client.getEndpoint().getOutInterceptors().add(new DemoOutInterceptor(m_demoInfo));
// However, we only need a custom inbound Interceptor if we know that the server
// is sending back encrypted messages.
if (m_demoInfo.encEnabled && m_demoInfo.encInbound)
{
client.getEndpoint().getInInterceptors().add(new DemoInInterceptor());
}
}
Refer the demo source to view the code snippets above within their context.