-
Notifications
You must be signed in to change notification settings - Fork 19
ESGF_Registration_Service
The purpose of the ESGF Registration Service is to allow users to apply for membership in special access control groups that may be needed to access specific data collections. The Registration Service deployed at each ESGF node is responsible for granting membership in the access control groups managed by that particular node, even to users that may have registered at another node. Once membership has been granted, the corresponding access control attributes may be retrieved by querying the ESGF Attribute Service at that same node.
Clients interact with the ESGF Registration Service by submitting a (signed) XML request, and parsing a (signed) XML response. The URL of the ESGF Registration Service used by a client is advertised in the ESGF XML Registry, and must be invoked through the POST method. Although the actual registration process may take some time, the request/response interaction between the client and server is synchronous (i.e. the client may block processing while waiting for the server response, which should be fast).
Note that the ESGF Registration Service API specifies only the format of the (XML) request and response documents that are consumed and produced by the service. Each service implementation is free to implement the registration process in any way that is suited for that site: through automatic approval, manual approval, etc.
TODO: sign the XML request and response documents.
The XML registration request document contains the following mandatory fields:
-
user : a unique identifier for the user requesting registration (typically, the user's OpenID). If no record for that user is found at the node, a new record must be created by the Registration Service (in the cases that registration is granted).
-
group : the globally unique name of the requested access control group. It must already be known to the Registration Service.
-
role : the specific role that the user is requesting. It must already be known to the Registration Service.
The XML registration request _ must _ be submitted through an HTTP POST request, as the value of the HTTP parameter named xml .
Example [ registration request ](https://github.com/ESGF/esgf.github.io/wiki/E SGF_Registration_Service_Examples)
TODO: allow for optional fields _ first_name _ , _ last_name _ , _ email _ ? Or should they be retrieved through the user's Attribute Service ?
The XML registration response contains the following mandatory field:
- result : status code of type string representing the outcome of the registration request. Valid result values are:
* EXISTING : the user was already approved to be in the requested group with the requested role
* SUCCESS : the user was registered in the requested group with the requested role
* PENDING : the user registration request was submitted, but required administrator approval
* DENIED : the user registration request was denied
* UNKNOWN : the result of the operation is unknown
- message : optional feedback message sent to the client
In case an error arises on the server side, the Registration Service must send an HTTP response with status code = 500 ("Internal Server Error").
Example [ registration response ](https://github.com/ESGF/esgf.github.io/wiki/ ESGF_Registration_Service_Examples)
TODO: implement more complex processing of registration request by the service