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.

administration access requirements

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.

Menu option No login required Login required
* Site Table
* VO Management
* VOName correction
* active, inactive or all
* CPU Info
* Roles
* Certificates
* Job Usage Replication
* Metric Replicatino
* System status: normal or detailed
* Administration
* Installation
* Security
* Replication
* Gratia Service Settings

List of requirements.

  1. For an instance of a Gratia collector, at least one Gratia administrator must be defined.
  2. The Gratia administrators are identified and managed by the VO
  3. A user grid certificate will be used to identify the administrator

administration access design

The identity of a Gratia administrator will be defined in the TOMCAT_HOME/gratia/ file.
  • 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. 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.

  1. This will be in the form of an OS file located at TOMCAT_HOME/gratia/
  2. File name is defined by the key service.voms.connections=voms-servers in the file
  3. File permissions of 644
  4. 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 file.
    • The 2nd token is the url of the VO's VOMS server.
  5. Initially, this file will be manually maintained. In the long term, this file should be distributed by the OSG GOC.
  6. 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.
./gratia/voms-servers file:
  # 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:

  1. 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.
  2. If the user desires administrative update options, the user will select the appropriate menu option.
  3. The login process will read the imported user certificate from the browser to access the identity (DN/CA,subject/issuer) of the user.
  4. Depending on the specified values in the 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 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 file.
  5. If the user is not authorized,
    • the left frame menu will remain unchanged.
  6. 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:

  1. 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.
  2. 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 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.
  3. 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 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. file:
# 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.)

  1. 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.

  2. If there is not at least one service.admin.FQAN.n entry (or the entry is corrupted) in the file, display a message similar to:
    Access denied: There are no valid service.admin.FQAN parameters in the file. Refer to your Gratia documentation to configure this parameter.

  3. 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 file could not be found in the voms-server file. Check your configuration.

  4. 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>

  5. 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.

administration access open issues

  1. 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 ''
    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.

reporting view requirements

This section has not been defined yet.

reporting view design

reporting view open issues

Major updates

-- JohnWeigand - 25 Feb 2008
Topic revision: r13 - 06 Dec 2016 - 18:12:35 - KyleGross
Hello, TWikiGuest


TWiki | Report Bugs | Privacy Policy

This site is powered by the TWiki collaboration platformCopyright by the contributing authors. All material on this collaboration platform is the property of the contributing authors..