Storage solutions will tend to be institution-specific. A common choice is to use the Windows Active Directory as an attribute source. Both the IAMSECT project at Newcastle University and the SECURE project at LSE have identified that the Active Directory may not contain enough information. Also, if the Active Directory doesn't already contain the requisite information, trying to add it is difficult. There is more information regarding this in other IAMSECT deliverables and the SECURe project documentation directory[6]
. If another solution is sought, then initially it will necessary to identify a suitable institutional data feed or feeds.
The Attribute Authority (AA) is a service at the Identity Provider that is responsible for sending attributes associated with a user, to a trusted 3rd-party. The AA applies an Attribute Release Policy (ARP) to attributes that are made available to target resources. The ARP defines which specific information is released about a user. At the service provider, the SHIRE (SHibboleth Index Reference Establisher) component interacts with the SHAR (SHibboleth Attribute Requester). The SHAR requests attributes about the user, directly from the AA. A decision is then made by the SHAR (and the notional concept of a ‘Resource Manager’), based upon the requested attributes as to whether the user is authorised to access the resource. Although authentication is not actually part of the Shibboleth specification, it is inherently part of the authorisation process that the user’s identity is verified by their local institution. The mechanism for doing this is left up to the institution itself to define and operate.
Once the attributes have been collected by the identity provider, they need to be aggregated.
Aggregated attributes can be used to provide a user profile. A user's identity may be represented as an aggregate of all his/her attributes, or aggregates of subsets of attributes, such as those associated with a user’s professional identity as distinguished from his/her personal identity. No single attribute should identify a user on its own.
Shibboleth has a particularly strong focus on maintaining user privacy and controlling the release of user-specific information (such as personal attributes) to service provider’s external to the user’s organisation. Aggregation should only happen at the origin not on the target at the service provider; this should be a part of a federation's policies. Although the need for user privacy can been expressed in a policy, such policies may be vulnerable to being bypassed by data aggregation. This is an extension of the problem of propagating trust via delegation to a federation; i.e. how does a user meaningfully restrict and control the use of data in services that are invoked only indirectly?
Institutions need to have the right to collect and aggregate data in this way. There is no reason why all of anyone’s personal information should be held on one server, and many reasons why it should not be. However, when the person wants to access their information, and control other people’s access to it, it is important that they can have access to all of its parts, and access it in an easily-understood structure.
The ability to enable users to control the selective release of attributes to targets is an inherent property of the Shibboleth model. The extent to which this is a requirement for simple inter- and intra-institutional use, and the interaction of institutional policy and user choice will be investigated by the AMIE[7] Project at Edinburgh University. Possible mechanisms to control how users will specify release policy choices will also be considered during the SDSS project at Edinburgh.