Which individual attributes are chosen to make each authorisation decision will be determined by the following factors:
the attributes that are required by the online application;
the institution's privacy policy;
which attributes can be collected from users in a timely and scalable manner.
Most of the currently contemplated attributes for use in U.K. and U.S. federations are simple and will probably present few technical issues to identity providers wishing to provide them. However when one begins contemplating attributes for internal use or attributes required for complex applications then technical concerns about how an identity provider would aggregate this information begin to emerge. While the use of most simple attributes will be determined by the interplay of application requirements and privacy concerns, technical concerns are going to determine what can and can’t be used as attributes in these more complex cases. There are several technical issues which may impact on the ability of an institute to use certain attributes. The first is the ability to obtain the attributes in a timely and scalable manner. The second is whether attribute are stored in a suitably structured store or stores.
In order to use attribute with Shibboleth, the attribute aggregation process needs to be able to access and aggregate user attributes in a reasonable amount of time, i.e. seven seconds would be a reasonable figure to aim for. Therefore it is likely the the institution will need a reasonable and performant attribute store. Institutional grade stores like Microsoft Active directory, openLDAP, MSSQL sever, MYSQL, Postgress etc. would be suitable; whereas personal grade data stores like Excel or Access databases would not be suitable.
At present the facility for aggregating together attributes within Shibboleth is reasonably flexible and robust, however is not as flexible as may be required by some institutes. The current facility allows institutes to query both ldap and jdbc stores in order to obtain attributes. It is even possible to query both at the same time. However it is not possible to use conditional logic for obtaining attributes. This may be a problem where data about different user populations is held in different forms in different stores. For example if staff and student data are held in separate systems with different formats it would first be desirable to query to see if the user was staff of student then adjust the next query based on the reply in order to obtain the required attributes. If this is required, then a system to do this would have to be hand made. Shibboleth does support Java plugin classes to achieve this, however it would be a burden on that institute and would require someone with the requisite Java skills.
Another approach may be to try and decouple the attribute aggregation process from the Shibboleth infrastructure. If the Shibboleth identity provider were able to query a webservice in order to obtain attributes about a user then the webservice could be written on any platform in the language most suitable for querying the institution datastore. At present Shibboleth requires that the person who understands the structure and location of an institution's data knows Java in order to make attibutes available to the software. It would be better if this person could program in their language of choice (e..g. C# and VB for Microsoft based infrastructures, ABAP for SAP, etc) and then make the results available via a webservice. In many institutions the attribute aggregation process is a valuable piece of business logic which it would be desirable to reuse.
The process of managing attributes is fundamental to the successful implementation of Shibboleth. It may well be reasonable to allow individual users to set some attributes for themselves yet be prevented from setting others, e.g. those determining access to national services. It would be easy to set up a separate directory to hold these attributes, but for a properly scalable solution this attribute store will need to be tied in very firmly with institutional databases.
The Attribute Management in an Institutional Environment (AMIE)[1] project has predicted that institutions will be faced with dealing with at least four different environments in which attributes for users must be held and managed. These attributes will control:
access to national facilities: in most cases the attributes needed are relatively simple there are significant exceptions. At first glance the required attribute for a site licence is simply that the person is a ‘member’ of the institution. However, there are already national services which either restrict access to known individuals (Ordnance Survey) or restrict access to a particular group of users (medics);
access to control access to (mainly) learning environments in small scale inter-institution collaboration: Institutions are increasingly collaborating with each other; the generic issues of who defines attributes, the ability to set attributes and trust needs to be established. Although the collaboration may be at the level of department, the level of authentication will lie at an institutional level in order to tie up who belongs to which institution;
access to resources of Virtual Organisations: Although the issues associated with this aspect appear similar to the previous item, the ownership of the right to define attributes lies with the ‘virtual organisation’ rather than the union of the institutions concerned. These issues are the same as those governing the management of federations;
access to locally held resources that need to be constrained to a particular group: There is a huge demand in institutions to control access for a set of people who do not fit neatly into a tidy organisational area. Shibboleth has the potential to enable this in a simple, scalable way but the mechanisms need investigation and documentation.
Although there is clearly some overlap across the above groupings, the ability to define the attribute, to assign it, and the trust patterns needed to sustain the activities are different in each case.
Managers need to be aware what information is actually available from institutional management information systems, as this will be key to populating the attribute store that Shibboleth will use. Since different Service Providers may require different attributes, there will be a core set of attributes that it is necessary to store for each individual. Rights to keep data must be ascertained, though since holding this type of data is key to the institution fulfilling its contract to the staff and students, these rights are granted.
It is worth noting that, in the case of a Shibboleth connection, no personal data which comes under the control of the Data Protection act should be exchanged, therefore, the act does not apply. Shibboleth also gives privacy control on release of attributes. An Identity Provider would contract with the Federation that it will release data as necessary for authentication and authorisation processes; Service Providers will be contracted to only request necessary data about individuals in order to authorise use of the resources they protect. In many cases all data will be anonymised, e.g. in the case of an institutional subscription, the only data needed to authenticate individuals is "affiliation to university x".
The JISC Data Protection Code of Practice for the HE and FE Sectors provides guidance on best practice concerning the retention of records containing personal data (version 2 is available at: http://www.jisc.ac.uk/index.cfm?name=pub_dpacop_0101).