UNiDAYS from MyUNiDAYS Ltd

Page last modified on 11 April 2024, at 02:18 PM (initially posted on 28 June 2011)

UNiDAYS is an exciting resource for FE and HE students delivering money saving advice, student-only promotions and networking opportunities. For UK federation members, the UNiDAYS service should be accessed via VerifID, this should be transparent to end-users. Identity Providers within the UK federation should not exchange metadata directly with UNiDAYS and our metadata publications reflect this situation. For participants in other federation via eduGAIN, your local federation may have other arrangements in place for access to UNiDAYS. The UK federation exports a UNiDAYS service provider with entityID https://verify-a.myunidays.com/shibboleth to the eduGAIN to support access for non-UK participants.

The UNiDAYS SP expects to receive a minimum of:

1. ONE of eduPersonScopedAffilation OR eduPersonPrimaryAffiliation OR eduPersonAffiliation

AND

2. ONE of eduPersonPrincipalName OR eduPersonTargetedID

Note:

1. The only attribute that an identity provider must release for its users to be able to access many services that are licensed for use by everyone at a particular organisation is eduPersonScopedAffiliation. This is a scoped attribute, which might, for example, have the value "member" in scope "uni.ac.uk", often written as:

It is used for the basic authorisation decision: does uni.ac.uk subscribe to the service in question? If so, the user is allowed access. The service provider will maintain its own list of which organisations (scopes) can access its service. For allowed organisations, the federation's Technical Recommendations for Participants indicate that, in HE/FE, users with scoped affiliation values from the set {member, student, staff, faculty, employee} are typically authorised to access content licensed on the basis of the JISC Model Licence, while {affiliate, alum} are not.

While a Shibboleth identity provider can generate eduPersonScopedAffiliation statically by setting the required value in attribute-resolver.xml, this should only be done when it is known that all users are authorised. Otherwise, the value can be picked up from your LDAP / Active Directory as described on the IdP setup page.

Users of other IdP software should check their documentation.

2. Many services can make use of the eduPersonTargetedID attribute. This is a persistent opaque identifier, which enables service personalisation (remembering data about a user over different login sessions) without the service provider knowing who the user is. If the identity provider supplies the eduPersonTargetedID attribute, the session is treated similarly to an Athens personal account. Otherwise, the service's personalisation features (e.g., saved searches) may be disabled, though the service will still function in the same way as with Athens shared accounts. With some services (e.g., Zetoc Alert) this attribute is mandatory. If so, it is marked as "Required/Yes" in the table in Attribute Usage.

For a Shibboleth IdP, generation of eduPersonTargetedID in attribute-resolver.xml is described on the IdP setup page.

Release of eduPersonTargetedID by attribute-filter.xml is described further down the same page.

Users of other IdP software should check their documentation.

8. When a service provider permits or requires individual user registration, they will require the identity provider to present eduPersonTargetedID or eduPersonPrincipalName. This allows logins to be related back to the user's registration details.

NB: in general we recommend the use of eduPersonTargetedID as presentation of eduPersonPrincipalName has implications under the DPA. Configuration of eduPersonTargetedID is described in note 2 above.