AAF Mini Grants

AAF Sites

University IT Benchmarking

Overview

The CAUDIT IT Profile and Benchmarking System enables IT Directors and their staff to access and manage University IT departments’ profile data, including major systems in use and benchmarking data, including official government data and university specific information. The primary goal of the mini-grant project is to improve CAUDIT member and wider user accessibility to the CAUDIT IT Profile and Benchmarking System. The grant aims to streamline both authentication using the AAF and authorisation – with functionality for CAUDIT staff to manage read/update access and the ability on demand from the CAUDIT member to grant delegated update access to the benchmarking data. The expected outcomes are wider access and use of IT Profile and Benchmarking data across the Australian and New Zealand Higher Education sector, the data extract facility and canned reports, improved control over access to sensitive data subject to the CAUDIT Acceptable Use Policy (AUP) and reduced administrative demands on CAUDIT and UniSA staff.

Mini-grant Project Team Contacts

  Name Position Phone Email
Primary Mr Tony Dalwood Deputy Director: ISTS (UniSA) (08) 83025056 Tony.Dalwood@unisa.edu.

Mini-grant Activity Reports

March Activity Report

November Activity Report

Design Notes

Login Process

  1. Un-authenticated user accesses a section of the CAUDIT application website that sits "behind" the Shibboleth Service Provider.
  2. User's web browser is redirected to the Australia Access Federation's Discovery Service.
  3. User selects their home organisation and is redirected to their Shibboleth Identity Provider. (The home organisation decides how exactly they want to authenticate their users.)
  4. The user is redirected back to the Shibboleth Service Provider with an attached token and any attributes the IdP has been told to release to this SP. The token can then used by the Shibboleth Service Provider to resolve any further required attributes of the user.
  5. A user identifier (auEduPersonSharedToken) is passed through to a Entitlement Shibboleth Identity Provider. The Entitlement ShibIdP will retrieve the required attributes from a local data store and return them to the SP. (For the CAUDIT application, this is likely to be Entitlements, Account Status and Institution Name.)
  6. The Shibboleth Service Provider converts the available authentication and authorisation information into environment variables, and passes them up to the CAUDIT application.

Authorisation Process

  • user hits a registration page
  • this then notifies the CAUDIT administrator via either email or the application of the pending request
  • CAUDIT administrator approves/rejects the request. This approval is then recorded in the Entitlement data store
  • CAUDIT administrator needs the ability to see all granted entitlements, plus be able to remove entitlements

Required Attributes

The following attributes have been identified as the required list for the application.

Attribute AAF Level Source Webserver variable
auEduPersonSharedToken Core HomeOrg IdP HTTP_SHAREDTOKEN
displayName Core HomeOrg IdP HTTP_DISPLAYNAME
mail Core HomeOrg IdP HTTP_MAIL
telephoneNumber (desired only) Recommended HomeOrg IdP HTTP_CONTACTPHONE
topLevelOrg (o) Core HomeOrg IdP HTTP_ORGANISATION
cauditContactPhone None Entitlement datastore HTTP_CAUDITCONTACTPHONE
cauditEnabled None Entitlement datastore HTTP_CAUDITENABLED
cauditInstitution None Entitlement datastore HTTP_CAUDITINSTITUTION
cauditInstitutionRole None Entitlement datastore HTTP_CAUDITINSTITUTIONROLE
cauditSiteAdmin None Entitlement datastore HTTP_CAUDITSITEADMIN

Entitlement Data Store

Proposed Configuration
We will be trialling the Locally managed entitlements method, with UniSA writing a front-end to support the entitlement management.

The proposed solutions can be broken down into the following categories:

  • how does the entitlement information get to the application
  • where is the entitlement information stored
  • how is the entitlement information managed
Method Entitlement information Entitlement store Entitlement management
Application managed entitlements (non-Shibboleth resolved entitlements) The application is responsible for looking up entitlement information, based on a supplied username. The application is responsible for storing the entitlement information. It could either be stored internally in the application, or use an external data store. The application is responsible for providing a management interface to the entitlement information.
Externally managed entitlements External organisations will provide their users' entitlement information via their Shibboleth Identity Providers. The Shibboleth Service Provider sitting in front of the application will receive this information during the authentication process, and then pass it up to the application. It will be up to each external organisation to decide how they store this entitlement information. It will be up to each external organisation how they manage this entitlement information.
Locally managed entitlements The Shibboleth Service Provider is responsible for resolving the entitlement information by querying a third-party Attribute Authority, and then passing it up to the application. The entitlement information will be placed in an external data store, with a local Shibboleth Identity Provider configured to supply this information upon request. The application (or other in-house tool) is responsible for providing a management interface to the entitlement information.
Locally managed entitlements using SWITCH Group Management Tool The Shibboleth Service Provider is responsible for resolving the entitlement information by querying a third-party Attribute Authority, and then passing it up to the application. The entitlement information will be placed in an external data store, with a local Shibboleth Identity Provider configured to supply this information upon request. A third party tool will provide the management interface to the entitlement data. This tool will be hosted locally.
Federation managed entitlements using SWITCH Group Management Tool The Shibboleth Service Provider is responsible for resolving the entitlement information by querying a third-party Attribute Authority, and then passing it up to the application. The entitlement information will be placed in an external data store, with a federation-managed Shibboleth Identity Provider configured to supply this information upon request. A third party tool will provide the management interface to the entitlement data. This tool will be hosted by the federation.

Application managed entitlements (non-Shibboleth resolved entitlements)

In this scenario, the application is responsible for both managing user entitlements (such as viewing, adding and removing user entitlements) and also resolving the entitlements once it has been presented with authentication details from the user.

The authentication itself will be handled by the Shibboleth Service Provider.

Ease of implementation High This is only a slight modification to the current process.
Re-usability of method Medium The method is re-usable, but will require extra code in any application that wants to use it.
Portability of application Low-Medium If the application is using an external data store, it probably can't be moved out of an organisation without having to move the data, too. If the application stores this data internally, its portability is improved.
Ease of management High Application can be customised to support all the required management functions.
Risk Low Basically what is currently being done, except initial authentication will use Shibboleth rather than Active Directory.

Externally managed entitlements

This method places the burden of work on all the external organisations that want to use the CAUDIT application. As a Service Provider we would specify want entitlements need to be presented to use the application and possibly guidelines as to who would get these entitlements. It would then be up to each individual organisation to work out how then can get their Shibboleth Identity Provider to supply it.

If there is a need for vetting of user entitlements this method would require the CAUDIT administrator to talk to each appropriate organisation.

Ease of implementation Medium No extra work required for UniSA; pushes work out to external IdPs.
Re-usability of method Low-Medium Will require external IdPs to implement an entitlement management solution, but once such a solution is in place, it should be easier to add additional entitlements.
Portability of application High Application can be moved to another hosting site with no change (if it preserves the entityID).
Ease of management Low Each University will be responsible for authorisation claims; no central management possible.
Risk Medium Take-up will be slowed by waiting on external IdPs to set the required entitlements.

Locally managed entitlements

Here we slightly modify the first configuration by now making the Shibboleth Service Provider responsible for fetching user entitlement information to pass up to the application. To do this, it needs to be able to query an Attribute Authority. Normally, this should be a Shibboleth Identity Provider that knows about the desired attribute.

We will use UniSA's Shibboleth Identity Provider to be that Attribute Authority by placing the entitlement information in an Oracle database, and then configuring the IdP to talk to it using the RDBMS Data Connector.

The CAUDIT application will still be responsible for managing this data, so code will need to be written to allow administrators to view, add and remove user entitlements.

Ease of implementation Medium-High No real technology changes. Will require evaluation and testing of using an IdP to talk to Oracle and configuring the ShibSP to fetch arbitrary attributes.
Re-usability of method Medium The method is re-usable, but will require extra code in any application that wants to use it.
Portability of application Low If the application moves, its data store will need to move with it; this will then require another IdP to pick up the job of resolving entitlements.
Ease of management High Application can be customised to support all the required management functions.
Risk Low This just moves this resolution responsibility to the IdP and ShibSP, but not a complete reworking of the current application.

Locally managed entitlements using SWITCH Group Management Tool

The SWITCH Group Management Tool can be used to provide a centralised way of managing arbitrary group permissions. The tool itself integrates with Shibboleth to allow any federated user to register with it. Part of the registration process should uniquely identify the user – something like eduPersonPrincipalName, mail or auEduPersonSharedToken. These registered users can then be placed into arbitrary groups by a delegated administrator.

At login time, the Shibboleth Service Provider will still attempt to fetch this attribute from UniSA's IdP by providing the unique identifier, but now the IdP will need to know how to query this information out of the Group Management Tool. Hopefully, the GMT can store its information in a database, and so the lookup can be just another SQL query.

Ease of implementation Low A reasonable amount of time will probably need to be spent building and testing these new components.
Re-usability of method High With the management interface being moved to a separate tool, any application will not need to know how to manage or lookup entitlements.
Portability of application High De-coupling the application from its entitlements means that it can be moved without any changes. And as long as the management interface was accessible from the outside world, that would not need to move either.
Ease of management Medium (maybe) Management will be done via the GMT interface. Which we don't really know what it looks like.
Risk High There's a lot of new technology involved in this solution, so extra time may be required to test it out. We also need to examine the interface provided by GMT to see if it is appropriate, or whether we need to spend some development time there, too.

Federation managed entitlements using SWITCH Group Management Tool

This is the same as the previous solution except that now the AAF is managing a central entitlement data store based on the SWITCH Group Management Tool.

Ease of implementation Low, High No real work for UniSA; a lot more work for the AAF.
Re-usability of method High Any future applications that require entitlements will be able to use the same service.
Portability of application High De-coupling the application from its entitlements means that it can be moved without any changes. And having an AAF managed tool would mean that it should never have to be moved.
Ease of management Medium (maybe) Management will be done via the GMT interface. Which we don't really know what it looks like.
Risk Very High The AAF is about to start testing this feature, so currently has no real timeline as to when (or if) this will be a production-ready service. This could lead to delays in this project's timeline.

Configuration required to support the entitlement store

To use a Shibboleth Identity Provider as an Attribute Authority requires configuration changes on both the AA and the SP that will be using it.

Service Provider

Simple Aggreation Attribute Resolver details how to configure a ShibSP to use the SimpleAggregation AttributeResolver. The AttributerResolver entry in the shibboleth2.xml file changes to:

<!-- Enable use of Attribute Authority -->
 <AttributeResolver type="Chaining">
       <!-- Use a SAML query if no attributes are supplied during SSO. -->
     <AttributeResolver type="Query" subjectMatch="true"/>

     <AttributeResolver type="SimpleAggregation" attributeId="sharedtoken" format="urn:oasis:names:tc:SAML:2.0:uniqueid-format:direct">
       <Entity>https://shibaa.unisa.edu.au/idp/shibboleth</Entity>
       </AttributeResolver>
</AttributeResolver>
Format of attributeId

The attributeId will be encoded via the format specifier. This means that the IdP will need to be told how to decode the value. This is covered in the Attribute Authority section.

The attribute-map.xml file needs to be updated to tell the ShibSP how to decode and parameterise the application-specific variables returned by the Attribute Authority.

<!-- CAUDIT attributes -->
 <Attribute name="urn:mace:shibboleth:2.0:unisa:cauditInstitutionRole:unspecified" id="cauditInstitutionRole"/>
 <Attribute name="urn:mace:shibboleth:2.0:unisa:cauditInstitution:unspecified" id="cauditInstitution"/>
 <Attribute name="urn:mace:shibboleth:2.0:unisa:cauditSiteAdmin:unspecified" id="cauditSiteAdmin"/>
 <Attribute name="urn:mace:shibboleth:2.0:unisa:cauditContactPhone:unspecified" id="cauditContactPhone"/>
 <Attribute name="urn:mace:shibboleth:2.0:unisa:cauditEnabled:unspecified" id="cauditEnabled"/>
Namespace for custom attributes

The name qualifier for each attribute is defined by the IdP, and is arbitrarily set.

Attribute Authority

Principal Connector (attribute-resolver.xml)

The Attribute Authority needs to be told how to resolve the key used to identify the user. Note that he xsi:type of Direct (rather than Transient) is used, as there is no user session information for the Attribute Authority to refer to. The nameIDFormat needs to match what was defined in the Service Provider's AttributeResolver entry.

<resolver:PrincipalConnector xsi:type="Direct"
                              xmlns="urn:mace:shibboleth:2.0:resolver:pc"
                              id="saml2DirectUID"
                              nameIDFormat="urn:oasis:names:tc:SAML:2.0:uniqueid-format:direct" />
Data Connector (attribute-resolver.xml)

The Attribute Authority will reference an Oracle database for retrieving the application-specific attributes. The definition of the data connector will also include the SQL query needed to fetch the attributes. This uses the RDBMS Data Connector.

<!-- Attribute Authority Connector -->
 <resolver:DataConnector id="UniSAaa"
                         xsi:type="RelationalDatabase"
                         xmlns="urn:mace:shibboleth:2.0:resolver:dc">
      <ApplicationManagedConnection jdbcDriver="oracle.jdbc.OracleDriver"
                                        jdbcURL="jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=yes)(ADDRESS_LIST=
                                            (ADDRESS=(PROTOCOL=TCP)(HOST=db1.oracle.example.com)(PORT=1521))                                            (ADDRESS=(PROTOCOL=TCP)(HOST=db2.oracle.example.com)(PORT=1521))
                                            (ADDRESS=(PROTOCOL=TCP)(HOST=db3.oracle.example.com)(PORT=1521))
                                            )(CONNECT_DATA=(SERVER=dedicated)(SERVICE_NAME=DBPRD)))"
                                    jdbcUserName="#USER#"
                                    jdbcPassword="#PASSWORD#" />
      <QueryTemplate>
          <![CDATA[
              SELECT * FROM VW_AUTHORISED_ATTRIBUTES WHERE UNIQUEID='$requestContext.principalName'
          ]]>
      </QueryTemplate>
 </resolver:DataConnector>
Attribute Resolution (attribute-resolver.xml)

Each individual attribute that will be pulled from the database needs to be defined. Key items are the resolver:Dependency on the data connector, the sourceAttributeID (which matches the database column name) and the name definition for each AttributeEncoder. The names used are arbitrary, but should be consistent, and hopefully unique to the organisation. The name information is then used on the Service Provider to decode the attributes.

    <!-- == cauditContactPhone == -->
     <resolver:AttributeDefinition id="cauditContactPhone"
                                   xsi:type="Simple"
                                   xmlns="urn:mace:shibboleth:2.0:resolver:ad"
                                   sourceAttributeID="CONTACT_PHONE">
         <resolver:Dependency ref="UniSAaa" />
         <resolver:AttributeEncoder xsi:type="SAML1String"
                                    xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                                    name="urn:mace:shibboleth:1.0:unisa:cauditContactPhone:unspecified" />
         <resolver:AttributeEncoder xsi:type="SAML2String"
                                    xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                                    name="urn:mace:shibboleth:2.0:unisa:cauditContactPhone:unspecified"
                                    friendlyName="cauditContactPhone" />
     </resolver:AttributeDefinition>
      <!-- == cauditEnabled == -->
     <resolver:AttributeDefinition id="cauditEnabled"
                                   xsi:type="Simple"
                                   xmlns="urn:mace:shibboleth:2.0:resolver:ad"
                                   sourceAttributeID="ENABLED">
         <resolver:Dependency ref="UniSAaa" /> 
         <resolver:AttributeEncoder xsi:type="SAML1String"
                                    xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                                    name="urn:mace:shibboleth:1.0:unisa:cauditEnabled:unspecified" />
         <resolver:AttributeEncoder xsi:type="SAML2String"
                                    xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                                    name="urn:mace:shibboleth:2.0:unisa:cauditEnabled:unspecified"
                                    friendlyName="cauditEnabled" />
     </resolver:AttributeDefinition>
      <!-- == cauditInstitution == -->
     <resolver:AttributeDefinition id="cauditInstitution"
                                   xsi:type="Simple"
                                   xmlns="urn:mace:shibboleth:2.0:resolver:ad"
                                   sourceAttributeID="INSTITUTION">
         <resolver:Dependency ref="UniSAaa" />
         <resolver:AttributeEncoder xsi:type="SAML1String"
                                    xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                                    name="urn:mace:shibboleth:1.0:unisa:cauditInstitution:unspecified" />
         <resolver:AttributeEncoder xsi:type="SAML2String"
                                    xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                                    name="urn:mace:shibboleth:2.0:unisa:cauditInstitution:unspecified"
                                    
friendlyName="cauditInstitution" />
     </resolver:AttributeDefinition>
      <!-- == cauditInstitutionRole == -->
     <resolver:AttributeDefinition id="cauditInstitutionRole"
                                   xsi:type="Simple"
                                   xmlns="urn:mace:shibboleth:2.0:resolver:ad"
                                   sourceAttributeID="INSTITUTION_ROLE">
         <resolver:Dependency ref="UniSAaa" />
         <resolver:AttributeEncoder xsi:type="SAML1String"
                                    xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                                    name="urn:mace:shibboleth:1.0:unisa:cauditInstitutionRole:unspecified" />
         <resolver:AttributeEncoder xsi:type="SAML2String"
                                    xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                                    name="urn:mace:shibboleth:2.0:unisa:cauditInstitutionRole:unspecified"
                                    friendlyName="cauditInstitutionRole" />
     </resolver:AttributeDefinition>
      <!-- == cauditSiteAdmin == -->
     <resolver:AttributeDefinition id="cauditSiteAdmin"                                  xsi:type="Simple"
                                   xmlns="urn:mace:shibboleth:2.0:resolver:ad"
                                   sourceAttributeID="SITE_ADMIN">
         <resolver:Dependency ref="UniSAaa" />
         <resolver:AttributeEncoder xsi:type="SAML1String"
                                    xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                                    name="urn:mace:shibboleth:1.0:unisa:cauditSiteAdmin:unspecified" />
         <resolver:AttributeEncoder xsi:type="SAML2String"                                    xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                                    name="urn:mace:shibboleth:2.0:unisa:cauditSiteAdmin:unspecified"
                                    friendlyName="cauditSiteAdmin" />
     </resolver:AttributeDefinition>
Attribute Release (attribute-filter.xml)

Because the Attribute Authority is designed to only support the required application-specified attributes, it has a very restricted filter list.

<?xml version="1.0" encoding="UTF-8"?>
  <AttributeFilterPolicyGroup
     id="ShibAAFilterPolicy"
     xmlns="urn:mace:shibboleth:2.0:afp"
     xmlns:basic="urn:mace:shibboleth:2.0:afp:mf:basic" 
    xmlns:saml="urn:mace:shibboleth:2.0:afp:mf:saml"
     xmlns:switchmd="http://www.switch.ch/aai/metadata/extensions"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:mace:shibboleth:2.0:afp classpath:/schema/shibboleth-2.0-afp.xsd
                         urn:mace:shibboleth:2.0:afp:mf:basic classpath:/schema/shibboleth-2.0-afp-mf-basic.xsd                         urn:mace:shibboleth:2.0:afp:mf:saml classpath:/schema/shibboleth-2.0-afp-mf-saml.xsd">
      <!-- Attribute Authority -->
     <!--RESOURCE_NAME#CAUDIT Profile and Benchmarking-->
     <AttributeFilterPolicy id="afp_for:https://caudit.unisa.edu.au/shibboleth">
         <PolicyRequirementRule xsi:type="basic:AND">
             <basic:Rule xsi:type="basic:AttributeRequesterString" value="https://caudit.unisa.edu.au/shibboleth" />
             <basic:Rule xsi:type="saml:AttributeRequesterInEntityGroup" groupID="urn:mace:aaf.edu.au:AAFProduction" />
         </PolicyRequirementRule>
         <AttributeRule attributeID="cauditContactPhone">
             <PermitValueRule xsi:type="basic:ANY" /> 
        </AttributeRule>
         <AttributeRule attributeID="cauditEnabled">
             <PermitValueRule xsi:type="basic:ANY" />
         </AttributeRule>
         <AttributeRule attributeID="cauditInstitution">
             <PermitValueRule xsi:type="basic:ANY" />
         </AttributeRule> 
        <AttributeRule attributeID="cauditInstitutionRole">
             <PermitValueRule xsi:type="basic:ANY" />
         </AttributeRule>
         <AttributeRule attributeID="cauditSiteAdmin">
             <PermitValueRule xsi:type="basic:ANY" />
         </AttributeRule>
     </AttributeFilterPolicy>
 </AttributeFilterPolicyGroup>