Standards for Technology in Automotive Retail
| Standards for Technology in Automotive Retail | |
The STAR Transport Group has selected Username/Password as the base method of authentication. The ability to authenticate via username and password is a base standard that all services must implement for the sake of interoperability.
![[Important]](images/important.png) | STAR Level 1 Requirement |
|---|---|
STAR1003 : All implementations are required to support Username/Password for authentication. |
WS-Security defines a UsernameToken element to be used to pass the username and password. Below is the XML syntax of this element.
Example 7.2. WS-Security Username and Passoword
<wsse:UsernameToken wsu:Id="..."> <wsse:Username>...</wsse:Username> <wsse:Password Type="...">...</wsse:Password> <wsse:Nonce>...</wsse:Nonce> <wsu:Created>...</wsu:Created> </wsse:UsernameToken>
Two methods to include the password are supported:
Plain Text, in which the password is passed in clear text
Hashed, in which the password is not transmitted, but instead, a one-way hash is generated from the password and used for authentication
If a clear text password is used then it is required that the appropriate transport level encryption is used, such as HTTPS. All passwords must be stored or persisted in an encrypted format.
The <wsse:Username> element carries the client identifier. For example, if the client is a dealer and the service provider is an OEM, the Username element will be the dealer’s identifier. Different service providers require different types of identifications to identify their clients. Therefore, the syntax of this element is flexible and will be agreed upon between the two communication partners.
Below are other possible examples on using the username field:
A password can be sent in clear text if a secure communication channel, such as HTTPS, is available between the sender and the receiver.
Example 7.7. Plain Text Password
<wsse:Security soap:mustUnderstand="1">
<wsu:Timestamp>
<wsu:Created>2003-06-04T03:48:32Z</wsu:Created>
<wsu:Expires>2003-06-04T03:53:32Z</wsu:Expires>
</wsu:Timestamp>
<wsse:UsernameToken>
<wsse:Username>JohnDoe</wsse:UserName>
<wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">Password</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>When a secure channel is not available, or when the message goes through intermediaries, a password digest can be used to avoid revealing the password. WS-Security defines fields and algorithms to carry authentication information securely. The specifications use a one-way hashing algorithm, SHA1, to encrypt the combination of the password, a time stamp, the creation date/time, and a nonce (randomly generated string) to generate a digest. The resulting digest is base 64 encoded SHA1 hash value that is carried in the UsernameToken and verified on the server side.
Below is an example of a UsernameToken carrying a password digest:
Example 7.8. Password Digest
<wsse:Security soap:mustUnderstand="1" >
<wsu:Timestamp>
<wsu:Created>2003-06-04T03:48:32Z</wsu:Created>
<wsu:Expires>2003-06-04T03:53:32Z</wsu:Expires>
</wsu:Timestamp>
<wsse:UsernameToken wsu:Id="SecurityToken-8a45f51b-fe46-4715-bdae-e596c36ad6be">
<wsse:Username>JohnDoe</wsse:Username>
<wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">
RvaxAmb2KhEQpFFJE+YXcyRy6E8==
</wsse:Password>
<wsse:Nonce>X6y15GC/WLYP8XY/YR3iIQ==</wsse:Nonce>
<wsu:Created>2003-06-04T03:48:32Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security> The advantages of the digest method over the clear text method are:
Passwords are not transmitted over the wire
Since the Created element is included in the generation of the digest, the message recipient can reduce the risk of replay attacks by inspecting this element and rejecting messages that are older than a set time window.
To further reduce the risk of replay attacks the recipient can reject all messages that come with duplicate nonce values since nonces are generated to be unique. To accomplish this functionality, the server needs to store the nonce values of incoming messages for a period of time greater or equal to the expiration duration of the message, and compare the nonces of incoming messages to the stored ones.
There are situations in which a password digest cannot be used, such as when the password is not available to both: the client and the server (when using LDAP binding, for example).