Short PULL-mode UVOS Howto for Unicore/X

This section shows all the basic steps which are required to setup a Unicore/X and UVOS to work in PULL mode. Important fact to note here (and in case of PUSH mode too) is how the user's group membership is encoded as an XACML attribute. Currently it is an attribute of string type (so DataType="http://www.w3.org/2001/XMLSchema#string") with its name (AttributeId) equal to urn:SAML:voprofile:group. The example policy below uses this attribute.

Note that there are two scenarios described. Many administrators might be interested in the 2nd one.

UVOS based authorization

In this scenario we will use UVOS to perform fine grained and centralized authorization of grid users. Required steps are:

  1. Add UVOS server's CA certificate to the Unicore/X's main truststore.
  2. Add Unicore/X's CA certificate to the UVOS server's truststore.
  3. This step is optional. If you enable trust delegation support in the VO configuration file (as in the example configuration below) you can jump to the next point.
    Add Unicore/X's DN (from its certificate) as a member to the UVOS service. You don't have to make it a member of any particular VO (or group). However it must have read permission to all groups where its users will be placed. UVOS documentation contains details.
  4. Add grid users to the VO and assign them appropriate attributes.
  5. Update uas.config file to enable VO subsystem. Here we will configure UVOS as the primary source and leave XUUDB to provide local mappings (which can override data fetched from UVOS). You should have the following entries:
    uas.security.attributes.order=SAML-PULL XUUDB
uas.security.attributes.combiningPolicy=MERGE_LAST_OVERRIDES
# ... here goes xuudb configuration

uas.security.attributes.SAML-PULL.class=eu.unicore.uas.security.vo.SAMLPullAuthoriser
  6. Configure vo.config file as described in the Configuration section. vo.config may look like this (it is with XLogin mapping turned on):
    vo.uudb.group=/Math-VO/UUDB/SiteA

vo.truststore=conf/votruststore.jks
vo.truststoreType=JKS
vo.truststorePass=the!server

vo.localServerURI=http://example.org:7777

# ##########################
# PULL mode configuration
# ##########################

vo.pull.enable=true

vo.pull.enableGenericAttributes=true

vo.pull.cacheTtl=20

vo.pull.voHost=uvos.example.org
vo.pull.voPort=2443
vo.pull.voPath=

vo.pull.verifySignatures=false

vo.pull.xlogin=true
vo.pull.role=true

vo.pull.enableTrustDelegation=true
  7. Configure Unicore/X security policy to require attributes defined and maintained by the UVOS. E.g. the following XACML fragment allows to reach TargetSystemFactory service only for the users which are both members of VO Example-VO and a VO group /Math-VO/UUDB/SiteA. Moreover those users also must have a standard Unicore/X attribute role with a value 'user'. It means that in UVOS service grid user must have urn:unicore:attrType:role attribute defined (it is the standard setting) with a value 'user'.
    <Rule RuleId="AcceptTSF" Effect="Permit">
        <Description>
                Accept selected users to reach TSF
        </Description>
        <Target>
                <Subjects>
                        <AnySubject />
                </Subjects>
                <Resources>
                        <Resource>
                                <ResourceMatch
                                        MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">
                                        <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI"
                                                >TargetSystemFactoryService</AttributeValue>
                                        <ResourceAttributeDesignator
                                                DataType="http://www.w3.org/2001/XMLSchema#anyURI"
                                                AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" />
                                </ResourceMatch>
                        </Resource>
                </Resources>
                <Actions>
                        <AnyAction />
                </Actions>
        </Target>
        <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">
                        <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
                                <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">
                                        <SubjectAttributeDesignator
                                                DataType="http://www.w3.org/2001/XMLSchema#string"
                                                AttributeId="role" />
                                </Apply>
                                <AttributeValue
                                        DataType="http://www.w3.org/2001/XMLSchema#string">user</AttributeValue>
                        </Apply>
                        <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:any-of-all">
                                <Function FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal"/>
                                <SubjectAttributeDesignator
                                                DataType="http://www.w3.org/2001/XMLSchema#string"
                                                AttributeId="urn:SAML:voprofile:group" />
                                <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
                                        <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">/Example-VO</AttributeValue>
                                        <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">/Math-VO/UUDB/SiteA</AttributeValue>
                                </Apply>
                        </Apply>
        </Condition>
</Rule>

Using UVOS instead of XUUDB

In this scenario we will use UVOS to store in central point mappings of certificates to UNIX logins (Xlogins) and roles of of our users. Basically speaking this is a somewhat simpler version of the first scenario (which was additionally configuring arbitrary authZ attributes). To do so:

  1. Perform steps 1-3 from the above scenario.
  2. Choose a group name for storing mappings for your site (actually it may be shared by many sites which use the same mapping). Let's assume it is /Math-VO/UUDB/SiteA. Add grid users to this group. Next assign them in the scope of the group attribute urn:unicore:attrType:xlogin with the value of Xlogin for the user, and attribute urn:unicore:attrType:role with the value of the user's role (usually its just user). Note that if you want to assign the same Xlogin/role to multiple users then you can define UVOS group attributes and set them for the whole /Math-VO/UUDB/SiteA group.
  3. You can use the same configuration file as in the above scenario so perform steps 5 and 6 of the above section. You don't have to modify default authorization policy (so step 7 above can be ignored).

    It is good to test a configuration with a VO Push test utility available in Unicore/X.