Authentication Using Username Token ProfileUsernameToken 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 requestors 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 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:
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 the demo source to view the code snippets above within their context. |