Gratia Access/Login Specification
This document is intended to serve as both a requirements and design specification for limiting access and visibility into the two web service user interfaces of Gratia:
- administration services
- reporting services
The Gratia administration is accessible as http(s)://<node.domain>:<port>/gratia-administration. It allows for viewing the status of the collector and for maintenance of several data tables.
The Gratia administration web user interface login will allow access to all update service menu options, otherwise only the read-only menu options will be available.
List of requirements.
- For an instance of a Gratia collector, at least one Gratia administrator must be defined.
- The Gratia administrators are identified and managed by the VO
- A user grid certificate will be used to identify the administrator
The identity of a Gratia administrator will be defined in the TOMCAT_HOME/gratia/service-configuration.properties
- For Gratia instances servicing multiple VO's, multiple entries are allowed
- The identity of the Gratia administrator(s) will be defined by specifying the FQAN (Fully Qualified Attribute Name) as defined by the VO. Note that "Capability=" is normally a part of the FQAN, but this attribute has been deprecated and thus will not be used. The top level group in the FQAN or the FQAN is, by convention within OSG, defined as the VO name of the VOMS server.
- In order to insure that the most current list of administrative identities is always used this file should be read each time the login service is invoked (explicitly or implicitly). An alternative method of insuring currency is to read the timestamp on the file and read it only when it has changed.
service-configuration.properties file entries:
service.admin.DN.john=/DC=org/DC=doegrids/OU=People/CN=John Weigand 458491
Note: the above entries show various examples of how the
identity of the Gratia administrators can be defined within a VO:
service.admin.FQAN.x = valid FQANs that give administrative access,
where x are unique numbers and/or letters
service.voms.connections = file located in tomcat/gratia containing
the voms URL(s) for each VO specified
or simply using a DN:
service.admin.DN.x = valid DNs that give administrative access,
where x are unique numbers and/or lettters
the value 'ALLOW ALL' will give access to all who have a valid certificate
The Gratia login process will need the identity of the OSG VO VOMS servers in order to authenticate the identity of the user.
- This will be in the form of an OS file located at TOMCAT_HOME/gratia/
- File name is defined by the key service.voms.connections=voms-servers in the service-configuration.properties file
- File permissions of 644
- The file will contain 2 tokens with whitespace as the delimiter. Contiguous whitespace is treated as a single delimiter.
- The 1st token is the VO name which will be top level group of the FQAN defined by the service.admin.FQAN.n key in the service-configuration.properties file.
- The 2nd token is the url of the VO's VOMS server.
- Initially, this file will be manually maintained. In the long term, this file should be distributed by the OSG GOC.
- In order to insure that the most current list of VOMS servers is always used this file should be read each time the login service is invoked (explicitly or implicitly). An alternative method of insuring currency is to read the timestamp on the file and read it only when it has changed.
# comment line
The user identity requesting login access will be retrieved from a grid certificate imported in their browser. The DN (subject) of the certificate and CA (issuer) of the certificate, in the following form, will be used:
DN: /DC=org/DC=doegrids/OU=People/CN=John Weigand 458491
CA: /DC=org/DC=DOEGrids/OU=Certificate Authorities/CN=DOEGrids CA 1
The procedure for logging in for the "happy-day" scenario is:
- When the administration page is initially accessed, the Status: normal page will be presented and at the left frame menu a list of menu options. The options displayed in gray color are those requiring login. The logout option is also displayed in gray color as it has no effect before login.
- If the user desires administrative update options, the user will select the appropriate menu option.
- The login process will read the imported user certificate from the browser to access the identity (DN/CA,subject/issuer) of the user.
- Depending on the specified values in the service-configuration.properties file the following are the authorization steps:
- if there are defined service.admin.DN.x keys, then these keys are checked against the presented DN. If there is a match or if a key has the value ALLOW ALL the user is given admin access and no other action is required.
- if there are defined service.admin.DN.x keys and there is no match with the presented DN (and there is no key with the value ALLOW ALL) then
- A pull-down/popup menu will be displayed showing the list of possible VOs containing users who are authorized for admin access to this Gratia instance.
- This list will be based on the set defined in the service.admin.FQAN.n parameters of the service-configurataion.properties file.
- Using the voms-server file (defined by the service.voms.connections key), the login process will access the VO's VOMS server selected by the user and provide another pull-down/popup menu displaying the set of FQANs for that user in the VO selected. The VOMSAdmin method below can be used to retrieve that set:
- listUsersWithRole (java.lang.String groupname, java.lang.String rolename)
- The user will then select the FQAN from the list.
- The login process will check the selected FQAN against the set of service.admin.FQAN.n values in the service-configuration.properties file.
- If the user is not authorized,
- the left frame menu will remain unchanged.
- If the user is authorized,
- the left frame menu will display all the menu options available in the normal link color including the logout option.
Additional login processing considerations:
- There is no need to query all the VOMS servers designated by the service.admin.FQAN.n list if the user is determined to be a Gratia administrator. Once is enough.
- In order to take into account the scenario where a user's Gratia administrative privileges have been revoked (similar to a CRL situation), a refresh parameter will be added to the system-configuration.properties file. The login process will implicitly re-authorize the user as though the user had selected the login menu option. This will be done "behind-the-scenes" when the user performs any action including a refresh of a page. This interval is the time between login authorization checks.
- In order to take into account a user being logged in with Gratia administrator privileges and leaving his browser unattended for an extended period, a timeout parameter will be added to the system-configuration.properties file. If a user has been inactive for the period specified, the login process will return the user to the "read-only" state and menu options (replacing the logout option with the login option). The user will have to explicitly login again.
# service.admin.refresh -> (expressed in minutes).
# This is time interval at which a user' admin authorization is re-checked.
service.admin.timeout-> (expressed in minutes).
# This is time interval at which a user' admin authorization is reset and requires
# an explicit login. This is only done if the user is inactive for this period of time.
Some special error handling conditions:
(Note: These are suggestions and subject to change based on feedback from the developer.)
- All error conditions should be caught and a "friendly" message displayed providing sufficient information to understand/resolve the problem. There should be no java stacktraces displayed to the screen.
- If there is not at least one service.admin.FQAN.n entry (or the entry is corrupted) in the service-configuration.properties file, display a message similar to:
Access denied: There are no valid service.admin.FQAN parameters in the service-configuration.properties file. Refer to your Gratia documentation to configure this parameter.
- If there is no voms-servers file (or no matching entries for the service.admin.FQAN.n entries, diisplay a message similar to:
Access denied: The following VOs for your service.admin.FQAN parameters in the service-configuration.properties file could not be found in the voms-server file. Check your configuration.
- There can be 1 to n VOs to search. If the user is denied (FQAN not found for the user) in the VO's specified, the process should generate a message similar to:
Access denied: You are not defined as a Gratia administrator in any of the following VOs: <list the VO names of the VOMS servers queried>
- Since there are multiple VO VOMS servers to interrogate, one or more of them may not be accessible at that point in time.
- If this condition exists and the accessible VO VOMS servers do not allow access, then display a message similar to:
Access denied: The following VO VOMS server were not accessible: <list the VO names of the VOMS servers that were inaccessible>
- If the user is authorized in one of the accessible VOMS servers, don't display any message. Just allow access to all menu options.
- Command line shutdown of update services using wget .
Currently the initd tomcat service, does a wget to stop the update services prior to stopping tomcat.
wget -O - -q 'http://gratia.opensciencegrid.org:8881/gratia-administration/systemadministration.html?action=stopDatabaseUpdateThreads'
This will not be allowed when the login access is implemented. An alternative is required.
Possible resolution: This needs to be investigated. Can we use the --certificate=file option (and maybe others are needed) of the wget command to pass either the http or host certificate that is needed by the collector to access the VOMS servers. We would have some special processing in the login process to recognize this.
Current implementation allows stopping/starting the database updating threads by using a special URL, different than the one mentioned above. This needs to be investigated further and take into account the implemented authorization mechanisms.
The Gratia reporting is accessible as http(s)://<node.domain>:<port>/gratia-reporting. It allows for viewing the accounting data only. There is no maintenance/update capability. The general intent in this area is to to allow various levels of visibility to the data:
- public-like data viewable by anyone
- VO level data viewable by members of a VO
- Individual user data (DN level) for members of a VO
The detailed requirements for this capability have not been fully defined yet.
This section has not been defined yet.
- 25 Feb 2008