Child pages
  • ShibXACML

The Shibboleth 1.x software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only.

Skip to end of metadata
Go to start of metadata

Shibboleth: XACML-ARPs

This page provides a patch that is extending Shibboleth by a new ARP-architecture, i.e.:

  • using XACML as policy language
  • using openLDAP for decentral storage of ARPs

After a short introduction, all required steps are explained to get the extension running.

Introduction

The task of identity management is organization-internal and central administration of data about coworkers, customers, partners
and guests as well as their access to local resources and services. This traditional solution of identity management covers
neither the rising necessity for the access to organization-external services and resources nor the efficient user
administration of partner enterprises (e.g. in B2B). Thus the question is, how organization-internal as well as -external
information systems and their users can be integrated and administered in domain-exceeding networks. Exactly hereby the
federated identity management (FIM) comes to cover those needs and requirements.

In federated identity management systems user-data, needed for authentication and authorization, has to be exchanged
between different instances (e.g. between two organizations, if a user of an organization wants to use services of another
organization). In order to run the exchange of user information within a controlled framework, attributes release
policies (ARPs) are used. With the help of the ARPs, guidelines can be set up, that restrict the transmission of data. By
regulating the release of data, the important aspect of data security can be guaranteed.

Regarding Shibboleth, yet the expressiveness of the Shibboleth-ARPs is only sufficient for relative simple scenarios.

Within the scope of a diploma thesis at "Ludwig Maximilian Universitaet" and "Leibniz-Rechenzentrum" in Munich,
Shibboleth 1.3c IdP has been prototypically extended by a new ARP architecture using the powerful policy language 'XACML' (see XACML Specification).

Structure of the thesis:

After an introduction and description of Shibboleth, the thesis describes scenarios within the range of FIM.
From these scenarios criteria are derived, which an ARP system must provide. In respect to these criteria,
well-known policy languages are examined regarding the suitability for ARPs. The best suitable policy language is
selected for the new architecture and its use is described in detail. On basis of the selected policy
language a new policy based privacy management architecture for Shibboleth is developed and imlpemented prototypically
in Java. The implementation uses an already existing policy decision point of Sun. Additionally a new priority-based
Policy-Combining-Algorithm is implemented. Examples, describing the configuration and the use of the new architecture, conclude the work.

New architecture:

The new architecture is using XACML as policy language to describe ARPs. In the new architecture can be expressed:

  • attributes to release
  • complex conditions (i.e. the use of several nested functions over more than one attribute is supported)
  • purposes
  • actions
  • obligations
  • subjects (Service Provider)
  • roles
  • combining algorithms for rules/policies
  • groupings of information
  • policies depending on external information like date or time
  • users or groups for which an ARP is valid

To see the complete work go to
Diploma Thesis
(diploma thesis is written in German).

For a quick start see the following section.

Set up the new architecture

For detailed information about how to make Shibboleth 1.3c using the new architecture, see the diploma thesis as
stated above. The points below are only summing up the steps to get Shibboleth using our investigated XACML-ARPs:

1) Apply Patch-file

Apply the attached patch-file 'shibPatch' to the source code of Shibboleth 1.3.c to achieve the new class files of shibboleth

  • change directory to '.../shibboleth/src/'
  • copy the patch-file to this directory
  • type in the linux-command 'patch -p1 < shibPatch'
  • compile the new source code
  • replace all class files in your working shibboleth IdP with the new ones
2) Configure openLDAP

Configure the ldap Server (for infos about using openLDAP see openLDAP) for enabling the storage of XACML-ARPs and usergroups

  • set up one (or more) ldap-server(s) (e.g. located at your IdP)
  • configure the Arp Repository in idp.xml like this:
    <ReleasePolicyEngine>
     <ArpRepository implementation="edu.internet2.middleware.
      shibboleth.aa.arp.provider.LdapArpRepository">
    	  <Path>ldap://ecample.com:389/dc=example,dc=com
    	  </Path>
    	  <Path>
    	  ...more LDAP-servers...
    	  </Path>
     </ArpRepository>
    </ReleasePolicyEngine>
    
  • include the following two schemes in ldap, for describing usergroups and ARPs:
	
attributetype (1.1.1.1.1
 NAME 'XACMLgroupName'
 DESC 'name of the group'
 EQUALITY caseIgnoreMatch
 SUBSTR caseIgnoreSubstringsMatch
 SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE)
attributetype (1.1.1.1.2
 NAME 'XACMLmembers'
 DESC 'multi-valued: members of the group'
 EQUALITY caseIgnoreMatch
 SUBSTR caseIgnoreSubstringsMatch
 SYNTAX '1.3.6.1.4.1.1466.115.121.1.15')
objectclass (1.1.1.2.1
 NAME 'XACMLgroup'
 STRUCTURAL
 MUST (XACMLgroupName \$ XACMLmembers))


attributetype (2.1.1.1.0
 NAME 'XACMLpolicyId'
 DESC 'name of policy'
 EQUALITY caseIgnoreMatch
 SUBSTR caseIgnoreSubstringsMatch
 SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE)
attributetype (2.1.1.1.1
 NAME 'XACMLpolicy'
 DESC 'contains the policy'
 EQUALITY caseIgnoreMatch
 SUBSTR caseIgnoreSubstringsMatch
 SYNTAX '1.3.6.1.4.1.1466.115.121.1.15')
attributetype (2.1.1.1.2
 NAME 'XACMLusers'
 DESC 'multi-valued: for whom policies are applied'
 EQUALITY caseIgnoreMatch
 SUBSTR caseIgnoreSubstringsMatch
 SYNTAX '1.3.6.1.4.1.1466.115.121.1.15')
attributetype (2.1.1.1.3
 NAME 'XACMLgroupNames'
 DESC 'multi-valued: groups for which users policies are applied'
 EQUALITY caseIgnoreMatch
 SUBSTR caseIgnoreSubstringsMatch
 SYNTAX '1.3.6.1.4.1.1466.115.121.1.15')
attributetype (2.1.1.1.4
 NAME 'XACMLtargets'
 DESC 'multi-valued: targets of policy'
 EQUALITY caseIgnoreMatch
 SUBSTR caseIgnoreSubstringsMatch
 SYNTAX '1.3.6.1.4.1.1466.115.121.1.15')
attributetype (2.1.1.1.5
 NAME 'XACMLroles'
 DESC 'multi-valued: roles for which the policy is'
 EQUALITY caseIgnoreMatch
 SUBSTR caseIgnoreSubstringsMatch
 SYNTAX '1.3.6.1.4.1.1466.115.121.1.15')
objectclass (2.1.1.2.1
 NAME 'XACMLpolicy'
 STRUCTURAL
 MUST (XACMLpolicyId \$ XACMLpolicy)
 MAY (XACMLusers \$ XACMLgroupNames \$ XACMLtargets \$ XACMLroles))
3) Create ARPs

Now you can create usergroups and XACML-ARPs, e.g.:

Entry for describing a group (stored under subtree 'ou=groups'):

dn:                     XACMLgroupName=testGroup,
                        ou=groups,
                        dc=example,
                        dc=com
objectclass:            XACMLgroup
XACMLgroupName:         testGroup
XACMLmembers:           user1
XACMLmembers:           user2

Entry for describing a policy, valid for the group stated above (stored under subtree 'ou=sitearps,ou=policies'):

dn:                     XACMLpolicyId=exampleArp,
                        ou=sitearps,
                        ou=policies,
                        dc=example,
                        dc=com
objectclass:            XACMLpolicy
XACMLpolicyId:          exampleArp
XACMLpolicy:            <Policy> 
 ...see Example ARP... 
 </Policy> 
XACMLgroupNames:        testGroup
XACMLroles:             defaultrole

Example ARP

Here is an example XACML-ARP. For description see the tag 'Description'.

 <Policy 
 xmlns="urn:oasis:names:tc:xacml:1.0:policy" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
 xmlns:context="urn:oasis:names:tc:xacml:1.0:context" 
 xmlns:condition="urn:mace:dir:attribute-def" 
 PolicyId="exampleArp" 
 RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:
 rule-combining-algorithm:ordered-permit-overrides"> 
 <Description>  
 Attribute to release: EduPersonNickname 
 Condition: only release eduPersonNickname, if
 eduPersonPrincipalName has the value of foo.bar
 Purpose: authorization 
 Action: read 
 Target: SP1 or SP2 or SP3
 Obligation: delete data after end of term
 Combination:
 - ARPpriority: combines all found applicable policies based on priority (parameter set in tag 'CombinerParameter')
 - ordered-permit-overrides: combines rules within this policy 
 Role: defaultrole
 </Description>
 <PolicyDefaults>
 <XPathVersion>
 http://www.w3.org/TR/1999/Rec-xpath-19991116
 </XPathVersion>
 </PolicyDefaults>
 <CombinerParameters>
 <CombinerParameter ParameterName="ARPpriority">
 100
 </CombinerParameter>
 </CombinerParameters>
 <Target>
 <Subjects> 
 <Subject> 
 <SubjectMatch 
 MatchId="urn:oasis:names:tc:xacml:1.0:function:regexp-string-match"> 
 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
 SP1|SP2|SP3
 </AttributeValue> 
 <SubjectAttributeDesignator 
 DataType="http://www.w3.org/2001/XMLSchema#string" 
 AttributeId="urn:oasis:names:tc:xacml:1.0:subject:service-provider"/> 
 </SubjectMatch> 
 </Subject> 
 </Subjects> 
 <Resources> 
 <Resource> 
 <ResourceMatch 
 MatchId="urn:oasis:names:tc:xacml:2.0:function:anyURI-equal"> 
 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">
 urn:mace:dir:attribute-def:eduPersonNickname
 </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> 
 <Rule RuleId="Rule1" Effect="Permit"> 
 <Target> 
 <Subjects> 
 <AnySubject/> 
 </Subjects> 
 <Resources> 
 <AnyResource/> 
 </Resources> 
 <Actions> 
 <Action> 
 <ActionMatch 
 MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> 
 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
 read
 </AttributeValue> 
 <ActionAttributeDesignator 
 DataType="http://www.w3.org/2001/XMLSchema#string" 
 AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"/> 
 </ActionMatch> 
 <ActionMatch 
 MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> 
 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
 authorization
 </AttributeValue> 
 <ActionAttributeDesignator 
 DataType="http://www.w3.org/2001/XMLSchema#string" 
 AttributeId="urn:oasis:names:tc:xacml:1.0:action:purpose"/> 
 </ActionMatch> 
 </Action> 
 </Actions> 
 </Target>
 <Condition 
 FunctionId="urn:oasis:names:tc:xacml:1.0:function:any-of-any">
 <Function 
 FunctionId="urn:oasis:names:tc:xacml:1.0:
 function:regexp-string-match"/>
 <Apply 
 FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
 foo.bar
 </AttributeValue>
 </Apply>
 <AttributeSelector 
 RequestContextPath="//context:ResourceContent/
 condition:eduPersonPrincipalName/text()" 
 DataType="http://www.w3.org/2001/XMLSchema#string"/>
 </Condition>
 </Rule> 
 <!-- ... nothing more to release ... --> 
 <Rule RuleId="releaseNothingMore" Effect="Deny"/> 
 <Obligations>
 <Obligation 
 ObligationId="data-has-to-be-deleted-after-end-of-term" 
 FulfillOn="Permit">
 <AttributeAssignment AttributeId="resource" 
 DataType="http://www.w3.org/2001/XMLSchema#anyURI">
 urn:oasis:names:tc:xacml:1.0:resource:resource-id
 </AttributeAssignment>
 </Obligation>
 </Obligations>
 </Policy> 

For errors or additional information see the "shib-error.log" after authentication with Shibboleth.

It is worth mentioning that the new architecture must not be seen as a finished work, in fact there are many
newly-created starting points.

  • Set ALLOWTOPICCHANGE = Main.MatthiasEbert

-- Main.MatthiasEbert - 05 Dec 2006

  • No labels