Authorization Service

The Authorization Service was introduced in R3.1. It exists to support open access to the BonFIRE infrastructure, allowing resource usage quotas and other restrictions to be imposed. The system is entirely group-based; quotas can only be imposed on a group and not on an individual user. The service maintains its own internal database of groups that is distinct from the main LDAP directory, as well as a database of resources that currently exist.

The restrictions supported by the service are as follows:

  • Compute quota – a group may be limited to owning a certain number of compute resources at any one time, and/or using a certain number of cores.
  • Storage quota – a group may be limited to using a certain quantity of storage at any one time.
  • Start/end dates – date restrictions may be imposed so that a group can only access BonFIRE infrastructure for a certain limited time.
  • Resource/location matrix – a group may be allowed to create only specific resource types at specific BonFIRE sites. For example, a group may be allowed to create compute resources and storage resources at EPCC, only compute resources at Inria, and no resources elsewhere.
  • Suspended flag – a group’s access to BonFIRE can be suspended completely by an administrator

The Authorization Service is not accessed directly by users or administrators; it provides a RESTful web service interface that is accessed by other components of BonFIRE. The Portal provides an interface for administrators to manage groups, quotas and other restrictions, while the Resource Manager queries the service for authorization whenever it receives a resource creation request.

In addition, there is a background service which periodically checks for groups that are exceeding their resource quotas and alerts administrators. This can occur despite the Resource Manager’s check due to the delay between resources being created and the Authorization Service discovering them (via messages on the MMQ).

APIs provided

The Authorization Service provies a REST API for services like the Resource Manager or Portal to contact to it for both querying and administrative actions over the different groups rights and quotas. This REST API allows the following commands:

List all groups info

Path:/groupinfo
Verb:GET
Content-Type:application/xml
Return code:200
Return payload example:
 
<GroupList>
        <group>group name</group>
        <group>group name</group>
        <group>group name</group>
        ...
</GroupList>

Create a new group

Path:/groupinfo
Verb:POST
Accept:application/xml
Incoming Payload Example:
 
<GroupInfo>
        <id>111</id>
        <startDate>start date</startDate>
        <endDate>end date</endDate>
        <suspended>false</supended>
        <maxAllocationUnitHours>10</maxAllocationUnitHours>
        <maxStorage>10</maxStorage>
        <maxNetworks>10</maxNetworks>
</GroupInfo>
Content-Type:application/xml
Return code:201
Return payload example:
 
<GroupInfo>
        <id>111</id>
        <startDate>start date</startDate>
        <endDate>end date</endDate>
        <suspended>false</supended>
        <maxAllocationUnitHours>10</maxAllocationUnitHours>
        <maxStorage>10</maxStorage>
        <maxNetworks>10</maxNetworks>
</GroupInfo>

List info of a specific group

Path:/groupinfo/{{group_id}}
Verb:GET
Content-Type:application/xml
Return code:200
Return payload example:
 
<GroupInfo>
        <id>{{group_id}}</id>
        <startDate>start date</startDate>
        <endDate>end date</endDate>
        <suspended>false</supended>
        <maxAllocationUnitHours>10</maxAllocationUnitHours>
        <maxStorage>10</maxStorage>
        <maxNetworks>10</maxNetworks>
</GroupInfo>

Update a new group

Path:/groupinfo
Verb:PUT
Accept:application/xml
Incoming Payload Example:
 
<GroupInfo>
        <id>111</id>
        <startDate>start date</startDate>
        <endDate>end date</endDate>
        <suspended>false</supended>
        <maxAllocationUnitHours>10</maxAllocationUnitHours>
        <maxStorage>10</maxStorage>
        <maxNetworks>10</maxNetworks>
</GroupInfo>
Content-Type:application/xml
Return code:202
Return payload example:
 
<GroupInfo>
        <id>111</id>
        <startDate>start date</startDate>
        <endDate>end date</endDate>
        <suspended>false</supended>
        <maxAllocationUnitHours>10</maxAllocationUnitHours>
        <maxStorage>10</maxStorage>
        <maxNetworks>10</maxNetworks>
</GroupInfo>

Delete a specific group

Path:/groupinfo/{{group_id}}
Verb:DELETE
Return code:204

Get the usage of a group

Path:/groupinfo/{{group_id}}/usage
Verb:GET
Content-Type:application/xml
Return code:200
Return payload example:
 
<UsageInfo>
        <storage>10</storage>
        <allocationUnitHours>10</allocationUnitHours>
</UsageInfo>

Check if it is possible to create a new resource

Path:/groupinfo/{{group_id}}/usagecheck?&computes=10;&cpus=10;&storage=10;
Verb:GET
Content-Type:application/xml
Return code:200
Return payload example:
 
<AuthzResult>
        <allowed>true|false</allowed>
        <reason>Some reason text</reason>
</AuthzResult>

Check if it is possible to create a new resource in an specific site

Path:/groupinfo/{{group_id}}/usagecheck?&resourceType=resource;&location=location;
Verb:GET
Content-Type:application/xml
Return code:200
Return payload example:
 
<AuthzResult>
        <allowed>true|false</allowed>
        <reason>Some reason text</reason>
</AuthzResult>

Delete a resource from the database

Path:/groupinfo/{{group_id}}/deleteresource
Verb:GET
Content-Type:application/xml
Return code:200
Return payload example:
 
<AuthzResult>
        <allowed>true|false</allowed>
        <reason>Some reason text</reason>
</AuthzResult>

Message queue use

The Authorization Service only reads from the MMQ, using its own credentials to connect to the ResourceUsage Exchange. Currently it listens to the following topics: res-mng.experiment.#: All the Experiment events comming from the Resource Manager: .compute.update,.compute.delete,*.compute.create,*.storage.create,*.storage.update,*.storage.delete, .experiments., .reservation..

Implementation details

The source code is in the BonFIRE svn repository under the folder “openaccess”. The requirements to develop it are the following ones:

  • Oracle JDK 1.6.x - You can download the correctly one for your platform at: JDK 1.6.x. After installed, you have to make sure JAVA_HOME variable is set pointing to the folder Java was just installed. (Note: The Enactor has never been tested with Java 7, so it is not sure that it is going to work with this new version. The Enactor has been tested and it is know that works without problem with OpenJDK 1.6.x).
  • Apache Ant - You can download from this address: Apache Ant .
  • Apache Tomcat - To execute the service, you can download it from: Apache Tomcat.
  • MySQL - Database to install the database schema for the service. MySQL.

In the root folder of the project you have the build.xml Apache Ant script. The default target builds the WAR file to be deployed in Apache Tomcat.

The service reads the database connection information from openaccess.properties in the WEB-INF directory. The dburl property should be set to the JDBC URL for the database, and the username and password properties to the database user name and password. Example:

dburl=jdbc:mysql://localhost/openaccess
dbuser=username
dbpassword=password

The MySQL script is also in the root folder of the project and the following figure gives a graphical representation of it.

../_images/database-schema.png

The management message queue listener also reads its MMQ connection information from the same file. The mmqurl property should be set to the queue’s URL (this includes username, password, hostname, port and virtual hostname), the mmqexchange property should be set to the exchange name, and the mmqtopics property should be set to a comma-separated list of topics to listen on. Example:

mmqurl=amqp://username:password@hostname:port/virtualhost
mmqexchange=resourceUsage
mmqtopics=*.compute.create,*.compute.update,*.compute.delete,*.storage.create,*.storage.update,*.storage.delete

Finally, the asynchronous usage checker reads two values from the same properties file. The emailaddress property specifies the address to which the warning emails should be sent when a group goes over one of their quotas. This can be a single address or a comma-separated list of multiple addresses. The usageperiod property specifies how often the check should run. It is in minutes. Example:

emailaddress=john.doe@nomail.com
usageperiod=60

The default for email is to use an SMTP server on localhost. If a different server needs to be used, it can be specified in a second configuration file, called email.properties, which should be created in the WEB-INF directory. This contains properties that are passed through to the Java mail API; please refer to the Java mail documentation if these need to be set.

The service will automatically create database entries for unknown groups when it learns of their existence through the API or MMQ. These new groups are created with default values for their metrics. The defaults can be specified in the openaccess.properties file. Example:

defaultgrouplifetime=14
defaultrlparams=epcc:all,ibbt:compute,ibbt:storage
defaultmaxcomputes=15
defaultmaxcpus=15
defaultmaxstorage=47185920

The default group lifetime is given in days; by default a newly created group has a start date of the date when it is created, and an end date this many days in the future. The default resource/location matrix is given as above by a comma separated list specifying which type of resources users are allowed to create on which sites. “all” means users can create any type of resource at this site. There is no equivalent wildcard for the sites.

If default values are not given in the properties file, hard-coded defaults in the code will be used instead.

Authorization Service Database

The database can be created in MySQL using the provided openaccess-db.sql file.

Table Of Contents

Previous topic

Accounting Service

Next topic

OpenNebula

This Page