This wiki is obsolete, see the NorduGrid web pages for up to date information.

Argus integration

From NorduGrid
Jump to navigationJump to search

ARCHED integration with Argus


Overview

Nordugrid ARC middleware requires a consistent mechanism to provide authorization based on user DNs. Existing ARC releases don't provide coherent solutions to address issues such as identical DN/UID mapping, DNs and policies maintenance, Global banning and unbanning of users over sites or specific services and support for accounting of pilot jobs. To overcome theses issues, Argus, gLite authorization framework has been opted as an effective solution to be integrated with HED in ARC1.

Plan

  • Implement emulation of CREAM using PEP library.
  • Test against existing Argus instances. Test reliability.
  • Implement EMI ES XACML profile.
  • Test it ass soon as there is instance of Argus implementing it.
  • (optional) Move implementation to direct XACML communication.

Goals

  • Providing a consistent approach for Identical DN/UID mapping which is not dependent to shared file systems
  • Support for accounting of pilot jobs
  • Global banning and unbanning of users over sites and services
  • Providing an administrative tool to maintain and control DN and policies

Requirements

  • Identical user mapping functionality
    • It should be possible to use a centralized approach to do the DN/UDI mapping in a consistent approach. Solutions based on shared file system or shared pool directory are not acceptable as they add dependency to the middleware since they are not all POSIX compliant. Besides in case of multiple users, each try to overwrite a shared entity which cause inconsistency.


  • User authorization
    • This feature enables site administrators to ban users based on DNs, CAs, VOs for a whole site or over multiple services.
    • The banning list and other policies can be created using SPL (a language to create and customized policies).


  • Support for pilot jobs
    • Pilot jobs are submitted through pilot submitter and the real owner of the jobs until they start execution on the worker nodes are not known which is important in the case of accounting. Using Argus as a centralized service, it should be possible to map users to a particular POSIXUID/GID.
    • Pilot jobs are two types: single-user and multi-user jobs. It's only multi-user pilot jobs which create authorization problems.
    • This feature is to be done as further work.

Technologies and third party libraries

PEP C client library

Pros

  • Few dependencies and footprints.
  • It provides easy integration.

Cons

  • It's not thread safe.
  • The API is not perfectly according to the ARC designs.


Hessian Messaging Protocols

Pros

  • Provides a thread safe approach.
  • More flexibility in API usage.
  • It's a very thin library which makes services available.
  • It supports binary serialization with many primitives.
  • It's very fast

Cons

  • It needs to be re-implemented to support Argus protocols.


LCAS: Local Centre Authorization Service

  • It handles authorization requests.
  • It provides local credentials needed for the jobs allow in execution to see if executable is allowed.


LCMAPS: Local Credential Mapping Service

  • It can load and run 'credential mapping' plugins.
  • It's a framework consists of the two components:
    • the plugin manager, which is in charge of managing, loading and running the LCMAPS plugins.
    • the evaluation manager, which does the calling of the LCMAPS plugins.


gLExec

  • It uses LCAS and LCMAPS to perform the major part of the authorization and mapping functionality.
  • It takes Grid credentials as input and the local site policy to authenticate and authorize the credentials.
  • gLExec performs the UID change.


XACML: eXtensible Access Control Markup Language

Integration

Hosting environment daemon in ARC is the place where authorization client is placed. Through identity mapping process a client will be created to communicate with the PEP daemon in Argus. As the beginning step, id mapper collects the Grid credentials and try to configure the authz client. This is to set up an interacting channel between the HED and the authorization framework to send and receive the XACML requests/responses. By default an authorization an authz request is composed of XACML subject, resource, action,and environment which is different from the response structure with these attributes: XACML decision element and obligation. HED authorization client uses gLExec LCMAPS plug-in to send and receive these requests and eventually parse the XACML response decision to authorize the user and the obligations to map a user to a local account. Currently as proof of concept an Argus provided client is in charge of send/receive messages to the PEP daemon.


Implementation

ARC PEP client should get the Grid user subject through sechandler plugin which is added to MCC handling TLS protocol. This client basically:

  • uses the "pep/pep.h" header
  • is initialized with pep_initialize()
  • at least has one PEP daemon URL option with pep_setoption(PEP_OPTION_ENDPOINT_URL, "http://pepd.example.org/authz")
  • sends an XACML Request containing Subject, Resource, Action and Environment according to:
    • xacml_attribute_addvalue(subject_attr_id,subjectid)
    • xacml_subject_addattribute(subject,subject_attr_id)
    • so on
  • submits the request and get the response using pep_authorize(&request, &response)
  • processes the response
  • decides about the Grid user request
  • releases the PEP client with pep_destroy()

More information about the Argus API to implement the required functionalities using C interfaces and modules can be found here:

The client should collect the request information from SecAttr class including: 

Request (1)
  RequestItem (*)
    Subject (*)
    Resource (*)
    Action (*)

Upon acquiring permission decision, client extracts the local user name and maps it to the Grid user identity.

Deployment and configurations

Argus components (https://twiki.cern.ch/twiki/bin/view/EGEE/AuthorizationFramework) could be setup locally or remotely. In order to set up your environment there are some dependencies (https://twiki.cern.ch/twiki/bin/view/EMI/ArgusDependenciesList) which need to be installed in your machine before installing the following components:

After installing all the components policies are required to be created in policy administration point. A sample policy is similar to: 

 resource "/home/testuser" {
     obligation "http://glite.org/xacml/obligation/local-environment-map" {
   }
   action "read" {
       rule permit { subject="CN=Test User,O=Test,C=..." }
   }
 }

This policy can be added from the command line in PAP: PAP_HOME/bin/pap-admin add-policy.

After installing these components you can test your Argus installations using command line to see if it responds to a test user such as below:


If settings are correct user should get a "Permit" response. To continue with the ARC1 installation, you need to checkout the ARC code from https://svn.nordugrid.org/repos/nordugrid/arc1/trunk and enable Argus in your configurations. Everything else is similar to a :

  • ./confiugre --with-argus=PEPC_HOME
  • make
  • make install


Finally it's time to run arched with the Argus settings, arched requires to know the PEP Url. This address can be defined in the arched config file such as this segment: 

 <Component name="tls.service" id="tls">
     <next id="http"/>
     <KeyPath>/etc/grid-security/hostkey.pem</KeyPath>
     <CertificatePath>/etc/grid-security/hostcert.pem</CertificatePath>
     <CACertificatesDir>/etc/grid-security/certificates</CACertificatesDir>   
     <SecHandler name="arguspep.map" event="incoming">
        <PEPD>url_to_pepd</PEPD>
     </SecHandler>
 </Component>

To run the arched you just need to issue this command:

  • arched -c arched_config.xml

Everything else is similar to a regular ARC usage with no Argus and you can use the rest of the other services with no changes.

Complete A-REX configuration example

A-REX service configuration example with Argus plugin. Plugin is configured to directly convert internal ARC authorizaion request into XACML-like supported by PEP API. All possible authorization attributes are filtered in order to reduce amount of possible permutations and keep only relevant ones. Those are TCP for local host IP address, TLS for client certificate attributes and AREX for requested operation. 

<?xml version="1.0"?>
<cfg:ArcConfig
  xmlns:cfg="http://www.nordugrid.org/schemas/arcconfig/2009/08"
  xmlns:tcp="http://www.nordugrid.org/schemas/tcp/2009/08"
  xmlns:tls="http://www.nordugrid.org/schemas/tls/2009/08"
  xmlns:arex="http://www.nordugrid.org/schemas/a-rex/LRMS/2009/08"
  xmlns:ip="http://www.nordugrid.org/schemas/a-rex/InfoProvider/2009/08"
  xmlns:lrms="http://www.nordugrid.org/schemas/a-rex/LRMS/2009/08"
  xmlns:authz="http://www.nordugrid.org/schemas/arcauthz/2009/08"
  xmlns:idmap="http://www.nordugrid.org/schemas/identitymap/2009/10"
  xmlns:argus="http://www.nordugrid.org/schemas/arguspep/2009/10"
  xmlns="http://www.nordugrid.org/schemas/loader/2009/08"
  xmlns:infosys="urn:infosys"
>
  <Server xmlns="http://www.nordugrid.org/schemas/arcconfig/2009/08">
    <PidFile>/var/run/arched_arex.pid</PidFile>
    <Logger>
      <File>/var/log/arched_arex.log</File>
      <Level>INFO</Level>
    </Logger>
  </Server>
  <ModuleManager>
    <Path>/opt/arc/lib/arc/</Path>
  </ModuleManager>
  <Plugins><Name>mcctcp</Name></Plugins>
  <Plugins><Name>mcctls</Name></Plugins>
  <Plugins><Name>mcchttp</Name></Plugins>
  <Plugins><Name>mccsoap</Name></Plugins>
  <Plugins><Name>identitymap</Name></Plugins>
  <Plugins><Name>arcshc</Name></Plugins>
  <Plugins><Name>arguspep</Name></Plugins>
  <Plugins><Name>arex</Name></Plugins>
  <Chain>
    <Component name="tcp.service" id="tcp">
      <next id="tls"/>
      <tcp:Listen><tcp:Port>60001</tcp:Port></tcp:Listen>
      <tcp:Limit drop="no">50</tcp:Limit>
    </Component>
    <Component name="tls.service" id="tls">
      <next id="http"/>
      <tls:KeyPath>/etc/grid-security/hostkey.pem</tls:KeyPath>
      <tls:CertificatePath>/etc/grid-security/hostcert.pem</tls:CertificatePath>
      <tls:CACertificatesDir>/etc/grid-security/certificates</tls:CACertificatesDir>
    </Component>
    <Component name="http.service" id="http">
      <next id="soap">POST</next>
      <next id="plexer">GET</next>
      <next id="plexer">PUT</next>
    </Component>
    <Component name="soap.service" id="soap">
      <next id="plexer"/>
    </Component>
    <Plexer id="plexer">
      <next id="a-rex">^/arex</next>
    </Plexer>
    <Service name="a-rex" id="a-rex">
      <! -- Backup mapping to local account in case Argus does not provide mapping -->
      <SecHandler name="identity.map" event="incoming">
        <idmap:PDP name="allow.pdp">
          <idmap:LocalList>/etc/grid-security/grid-mapfile</idmap:LocalList>
        </idmap:PDP>
      </SecHandler>
      <! -- Argus plugin configured to perform direct conversion and
           contact Argus PEP daemon at localhost -->
      <SecHandler name="arguspep.map" event="incoming">
        <argus:PEPD>localhost</argus:PEPD>
        <argus:Conversion>direct</argus:Conversion>
        <argus:Filter>
          <argus:Select>TLS</argus:Select>
          <argus:Select>TCP</argus:Select>
          <argus:Select>AREX</argus:Select>
        </argus:Filter>
      </SecHandler>
      <arex:endpoint>https://localhost:60001/arex</arex:endpoint>
      <arex:usermap><arex:defaultLocalName>griduser</arex:defaultLocalName></arex:usermap>
      <arex:gmrun>internal</arex:gmrun>
      <arex:gmconfig>/etc/arc.conf</arex:gmconfig>
      <arex:commonName>A-REX</arex:commonName>
      <arex:longDescription>ARC Execution Service</arex:longDescription>
      <arex:LRMSName>fork</arex:LRMSName>
      <arex:OperatingSystem>LINUX</arex:OperatingSystem>
      <arex:debugLevel>DEBUG</arex:debugLevel>
      <arex:serviceMail>support@cluster.org</arex:serviceMail>
    </Service>
  </Chain>
</cfg:ArcConfig>


ARC profile for Argus

Argus approach to serve different services was that every service has own XACML profile. Here we are starting to create such profile from collecting all existing attributes of ARC trying to match them to XACML context.

Now approach has changed. There is common XACML profile to be used by all services.

ARC attributes

Most ARC generic attributes may be found in Security Framework of ARC NOX. Attributes specific for services are supposed to be defined in service-specific documentation.

Subjects
Id (SubjectAttributeDesignator/AttributeId) Contains (AttributeValue) Source name
http://www.nordugrid.org/schemas/policy-arc/types/remoteendpoint client ip[:client port] of TCP connection TCP
http://www.nordugrid.org/schemas/policy-arc/types/tls/ca igner of first X.509 certificate in certificates chain presented by client (aka CA) TLS
http://www.nordugrid.org/schemas/policy-arc/types/tls/chain Subject of certificate in client's chain (multiple items) TLS
http://www.nordugrid.org/schemas/policy-arc/types/tls/subject Subject of last X.509 certificate in client's chain TLS
http://www.nordugrid.org/schemas/policy-arc/types/tls/identity Subject of last non-proxy certificate in client's chain TLS
http://www.nordugrid.org/schemas/policy-arc/types/tls/vomsattribute VOMS attributes extracted from whole client's chain of certificates TLS
http://www.nordugrid.org/schemas/policy-arc/types/http/path HTTP path without host and port part HTTP
http://www.nordugrid.org/schemas/policy-arc/types/soap/endpoint To element of WS-Addressing structure of SOAP Header SOAP
Resources
Id (SubjectAttributeDesignator/AttributeId) Contains (AttributeValue) Source name
http://www.nordugrid.org/schemas/policy-arc/types/localendpoint service ip[:service port] of TCP connection TCP
Actions
Id (SubjectAttributeDesignator/AttributeId) Contains (AttributeValue) Source name
http://www.nordugrid.org/schemas/policy-arc/types/http/method HTTP method HTTP
http://www.nordugrid.org/schemas/policy-arc/types/soap/operation SOAP top level element name without namespace prefix SOAP
http://www.nordugrid.org/schemas/policy-arc/types/soap/namespace Namespace of SOAP top level element SOAP
http://www.nordugrid.org/schemas/policy-arc/types/isis/operation ISIS service operation group. Possible values are isis, service, client. ISIS
http://www.nordugrid.org/schemas/policy-arc/types/storage/action Chelonia's operation
http://www.nordugrid.org/schemas/policy-arc/types/a-rex/joboperation Operation on A-REX job. Possible values are Create, Modify, Read. AREX
http://www.nordugrid.org/schemas/policy-arc/types/a-rex/operation Operation on A-REX service itself. Possible values are Admin, Info. AREX

A-REX profile

A-REX profile for Argus being developed is based on gLite profile "XACML Grid Computing Element Authorization Profile v. 1.0" https://edms.cern.ch/document/1078881/


CREAM emulation

Emulation is based on CREAM profile for Argus available at https://edms.cern.ch/document/1078881 .

Attributes mapping

CREAM ARC
Profile ID
Subject Identifier
Subject Issuer
Virtual Organization
FQAN
Primary FQAN
Resource Identifier
Action Identifier
Map to Local Environment
Map to POSIX Environment
Grant local administrator role
User Identifier
Group Identifier
Primary Group Identifier
Certificate Chain
VOMS Issuer

EMI ES XACML Profile

EMI XACML profile is described at https://twiki.cern.ch/twiki/bin/view/EMI/EmiJra1T4XACML .

Attributes mapping

EMI ARC
Profile Identifier
Subject Identifier
Subject Issuer
Virtual Organization
Group
Primary Group
Role
Primary Role
Resource Owner
Resource Identifier
Action Identifier
Retrieved from "https://wiki.nbi.ku.dk/w/index.php?title=Argus_integration&oldid=5293"