Difference between revisions of "SOA3 Authorization Service"

Latest revision as of 11:48, 10 December 2013

Overview

This section provides a deep description of the functionalities and the interfaces of SOA3 Authorization Service: an high level architectural description of the module is given at here.

SOA3 Authorization Module

The SOA3 Authorization module receives REST messages from the gCube Security Handler (whose implementation is named SOA3 Connector) with the following pieces of information:

• roles or attributes of the requester (user or service)
• Service Name and Service Class (ServiceClass:ServiceName) defining the Service Category requested
• Host containing the GHN which hosts the requested service, defining the Service Instance

The endpoint of the service is:

http(s)://hostname:port/policyService/policyquery

Authorization Process

The authorization process consists in the following steps:

1. SOA3 Authorization Service receive a REST POST Message containing the following JSON object:

  {  
   "attributes":[<attributeName1=attributeValue1>,
                 <attributeName2=attributeValue2> ...]
   "action":"<ServiceClass:ServiceName>"
   "resource":<Host>
  }

2. SOA3 Authorization Service translates the REST Message in an Authorization Query for the Argus Authorization Framework^[1]

3. Argus replies with a 200 (OK) if the authorization has been obtained, 401 (Unauthorized) otherwise

As alternative to point 1, it is possible to send a GET Message with the following path:

 http(s)://hostname:port/policyService/policyquery/rolequery/{role}/{action}/{resource}"

where "role" is the single attribute (considered a single role, in this case) and the other parameters have the same meaning of above.

In general the SOA3 Authorization Service is hidden by the SOA3 Connector Service, which transparently performs Authentication and Authorization in a single step.

References

1. ↑ https://twiki.cern.ch/twiki/bin/view/EGEE/AuthorizationFramework