Athens users will soon have the ability the link two or more separate Athens accounts into a single but independent identity; and access the combined set of resources. This facility has been developed and is currently being piloted by a number of Athens resource providers. Eduserv is working with the NHS Connecting for Health Design Authority to finalise the functionality and deliver the best possible user interfaces. For full details of this facility see the Account Linking White Paper.
When the testing cycles listed above have been completed and fully reviewed, we expect to consult with the steering group on deciding an appropriate release schedule and any further actions.
Account linking was developed to meet the needs of Athens administrators working in the UK education and healthcare communities. There are extensive and well-established links between the two sectors, e.g. university medical schools, teaching hospitals, etc, and this project is seen as part of the move towards greater collaboration across the two sectors, e.g. http://www.nhs-he.org.uk/.
The NHS Design Authority Group are also interested in this project, and recognise that it will help simplify access for their users.
Athens users with multiple affiliations will be able to link their accounts in a single one-off action that will allow them to subsequently login with a single set of credentials to an aggregated set of services. Athens administrators will retain overall control of user accounts: expiry dates, access rights, etc for their organisation's Athens accounts can't be superseded by other accounts they have been linked to. If an Athens account that has been linked is deleted, then the links to the other account(s) will also be deleted.
Any simplification in user access to electronic resources usually results in increased usage of those services, and it is anticipated that this will be the case for linked accounts.
It also formalises a process which has happened in ad-hoc manner, whereby a user may use multiple account to access a single service. The advantage of formalising this process is that when a user links an account, Athens will be presenting a single unique identifier to the service provider. The consequence of this is that personal information, saved searches etc, stored by the service provider will be shared between all their accounts, making the experience more consistent for the user. This has the further advantage that when users move between organisations, their persistent identity remains constant, removing the necessity to migrate saved information between accounts (or users losing it).
No. When an Athens user who has linked two or more accounts logs into a service, they will pass a list of Athens organisation IDs (org_IDs) to service providers. This should only enable Athens users to see the sum of the products or services that the user's various affiliations entitle them to.
There is no limit at present, but this will be reviewed in-line with the views of the communities we serve.
No. When Athens accounts are linked, an Athens 'identity' is created. An Athens account can only belong to one Athens identity.
Statistics will be logged against the account nominated as the primary account for a particular service provider. However, service providers will be able to view which organisations a user is affiliated with, so this information may be used to log additional information, based on the access policy employed by the service provider.
Yes, but only one AthensDA-enabled account can belong to an Athens identity.
Yes, but only one SAML/Shibboleth-enabled account can belong to an Athens identity.
Yes, multiple organisations will be available via attributes, in the same way that organisations are identified at present. The advantage of this is that more accurate information is being provided to a service provider, so that they may apply more accurate access-control policies, based on this information. At present users may access with multiple accounts in an ad-hoc fashion, but logging on with different accounts at different times. Linking of accounts means that the information which may be passed to a service provider will more accurately reflect the user's affiliation(s).
Personalisation will be stored against the user's persistent identifier. When a user links accounts, they establish an 'identity' which has its own persistent identifier. The advantage of this approach is that the user's identity remains with them even if they move between organisations. However, as far as service providers are concerned, they should continue using the persistent UID attribute, available via the Agent - there are no requirements to change the use of this attribute to support account linking.
In order to support users with multiple affiliations, we recommend that service providers make greater use of the organisation identifier attribute, which may possess multiple values in the case where a user has affiliations with multiple organisations. The recommended approach is for service providers to use an access policy which aggregates the permissions from the organisations to which the user has affiliations.
However, in order to maintain compatibility with resources which do not take this approach, the user will be able to nominate 'preferred' accounts, from which their primary organisation affiliation will be obtained, in preference to their other affiliations. In this case a service provider will use the first organisation identifier which they receive for a user.
We do strongly encourage Service Providers to make use of this additional information at the earliest possible opportunity.
The only explicit requirement for the Agent is support for multi-valued attributes. This has been supported in the Java Agent since version 3.6.4(released on 17 May 2004) and the C Agent since version 3.6.2 (release on17 June 2004). DSPs using other versions should consult with the DSP service desk.
April 2006