3.5 Command messages
3.5.12 Authentication for extended access - <Authenticate/>
The optional authentication functionality may be used to restrict the access to specific data objects.
The access can be restricted for the write and/or read access. The technical authentication scheme is based on RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication) which is commonly used to securely authenticate the access to web resources. A specific "username" and
"password" combination shall be used to gain access to a related set of read and/or write rights to
specific data objects. A possible way to manage the access rights is suggested in this specification document, but in general out of the scope of EXLAP.
3.5.12.1 General access and authentication scheme
If a client wants to access special or restricted data objects and functions it may first authenticate itself via the <Authenticate/> command and a user + password combination. After a successful authentication the data objects and their urls shall become visible and accessible for the <Dir/>, <
Interface/>, <Get/>, <Subscribe/> and <Call/> commands. If an authentication unique to a physical product is required, it is encouraged to use a specific username and password combination for each copy or instance of the product sold. How this can be realized or implemented is out of the scope of this document.
3.5.12.2 User based access management
A user based permission management is suggested, so that user with a password is allowed to access specific groups. By default there is an implicitly defined user with the name “default” and password “default” that belongs to the group “default” which includes all urls that are not otherwise assigned using the group management.
Proposed XML example configuration:
<Users>
<!-- "default" user - also implicitly defined/used -->
<User name="default" password="default">
<Permit group="default"/>
</User>
<!-- administrative user with default special access -->
<User name="admin" password="secret">
<Permit group="default"/>
<Permit group="admin"/>
</User>
</Users>
3.5.12.3 Group management
Using the group management every url can be assigned to groups, whereby a user can be assigned to multiple groups (modelled similar to the Unix file access system). By default every url is assigned to the “default” group and is accessible without any authentication.
Proposed XML example configuration:
<!-- Urls that will be protected -->
<Access>
<Assign url="LogEvent" group="admin"/>
<Assign url="GetProperties" group="admin"/>
<Assign url="SetProperty" group="admin"/>
<Assign url="ServiceControl" group="admin"/>
</Access>
Note: The proposed XML configurations are to understand as an example format for a XML based configuration of a potential EXLAP service implementation.
3.5.12.4 Authentication “challenge” phase
Authentication is an optional part of the EXLAP specification and done in a two way fashion based on the HTTP basic access authorization scenario [8]. The first phase requests a challenge/response digest authentication to gain access to protected data objects.
• Note 1: There shall only be one user credential active at one time.
This work is licensed under the Creative Commons Namensnennung-Weitergabe unter gleichen
• Note 2: A new <Authenticate/> sequence overwrites the old one.
• Note 3: Access rights are not additive but exclusive to the current user and password combination.
• Note 4: Data objects that are not accessible with the current credentials shall not be visible or accessible via the <Get/>, <Subscribe/>, <Interface/>, <Dir/> and <Call/> commands. A
“noMatchingUrl” error shall be returned in case a url can’t be accessed with the current credentials.
Format of the <Authenticate phase="challenge"/> command:
<Req>
<Authenticate phase="challenge"/>
</Req>
Example:
<Req id="555">
<Authenticate phase="challenge"/>
</Req>
Response format for <Authenticate phase="challenge"/>:
<Rsp {id="nr"}
{status="[ok|error|syntaxError|internalError|
notImplemented]"}
{msg="text"}>
<Challenge nonce="xsd:base64Binary"/>
</Rsp>
Response attributes and elements:
Attribute Description
status Optional attribute that returns the processing status of the request. The ok and error status values apply as described in section 3.3.3.
• notImplemented: The <Authenticate/> command is not supported by the server.
<Rsp id="555">
<Challenge nonce="SGFucy1DaHJpc3RpYW4gRnJpY2tl"/>
</Rsp>
challenge Response for and <Authenticate/> request that contains an element that contains the attribute "nonce".
nonce Contains one-time generated random data of 16 bytes encoded as xsd:base64Binary..
Example (not actual data):
<Rsp id="555">
<Challenge nonce="SGFucy1DaHJpc3RpYW4gRnJpY2tl"/>
</Rsp>
3.5.12.5 Authentication “response” phase
Optional command that is the second step in the challenge/response digest authentication (shall be implemented when <Authenticate phase="challenge"/> is implemented).
Format of the command:
<Req>
<Authenticate phase="response"
{user="xsd:string"}
{cnonce="xsd:base64Binary"}
{digest="xsd:base64Binary"}/>
</Req>
Request attributes and elements:
Attribute Description
cnonce Attribute specifying a client nonce (random generated 16 bytes used in the challenge-response) represented in xsd:base64Binary encoding. Default:
Empty string.
user Attribute specifying a user-id to authenticate against (e.g. "public"). Default:
Empty string.
digest Attribute specifying a calculated response digest represented in xsd:base64binary encoding. Default: Empty string.
Example (not actual data):
<Req id="56">
<Authenticate phase="response"
user="admin"
cnonce="SGFucy1DaHJpc3RpYW4gRnJpY2tl"
digest="SmVucyBLcnVlZ2Vy"/>
</Req>
The digest shall be calculated in the following way (all parameters in the MD5 method call are represented as 7-bit strings in UTF-8).
1. HA1 = MD5(user+":"+password)
2. HA2 = MD5(AsciiHex(nonce)+":"+AsciiHex(cnonce)) 3. DIGEST = MD5(AsciiHex(HA1)+":"+AsciiHex(HA2)).
Note: The digest shall be calculated on both sides in the same fashion. See RFC 2617 for more information concerning the underlying concept (see also http://tools.ietf.org/html/rfc2617 and http://en.wikipedia.org/wiki/Digest_access_authentication).
Response format for <Authenticate phase="response"/>: <Rsp {id="nr"}
{status="[ok|syntaxError|internalError|error|
authenticationFailed]"}
{msg="text"}/>
Response attributes and elements:
Attribute Description
status Optional attribute that returns the processing status of the request. The ok and error status values apply as described in section 3.3.3.
• authenticationFailed: The server shall respond with this status code when the authentication failed (i.e. password / user combination is incorrect, etc.) or user, cnonce or digest attributes are not present or empty.
<Rsp id="56" status="authenticationFailed"/>
This work is licensed under the Creative Commons Namensnennung-Weitergabe unter gleichen