OpenAthens LA support ended on 31 March 2020


Skip to end of metadata
Go to start of metadata

Attributes are the things you’re prepared to say about your users to the SPs and not every attribute will be passed to every SP. Some are not passed because the user isn’t in a specified category, some because the attribute is only released to a specified SP… and some because one or more SPs don’t need to know that. To add a new attribute, click the green plus button and choose the type.

This page can look daunting, but once you know what the bits mean it all makes much more sense.

On the left of the page is the list of existing attributes. At the top of the page are the system attributes and these are grouped there so that they can be evaluated first and used by other parts of LA which is why you find such attributes as username and scope there. Below them are the releasable attributes that can be passed to SPs such as ScopedAffiliation or TargetedID.

The attributes in this list have two parts to their name. First the attribute type (e.g. Fixed Value or Scripted) and then the attribute name (e.g. urn:mace:dir:attribute-def:eduPersonTargetedID or urn:oid:

If you click on an attribute in the list, you’ll see more information about it in the right hand pane.

This layout is typical with a target name, friendly name, system use checkbox and category box, but some attribute types will have additional fields. These are covered in the attribute types section below.

The basic attribute fields

These four fields come up on most attribute types

Target name

The name of the attribute – if it’s for an SP in a federation this name will probably be long as above, but if it’s for your own internal systems it can be whatever you like as long as it matches what the other end is expecting.

Friendly name

This creates the folders in the list of attributes on the left and allows you to group attributes or simply give them more accessible names. However you want to organise things is just fine.

For system use

If you tick this one, then the attribute appears in the top section of the list and can’t be released to service providers. More importantly it means that this attribute can be used in scripted attributes to make other releasable attributes.

Assign to user categories

Which categories of user should have this attribute applied to them – many (including all the system attributes) should be assigned to the Everyone category, but this is where you would specify a staff category as the only one to get a specific value - e.g. a scopedAffiliation value of 'staff'.

Attribute types

From Datastorename

Pulls a value directly from the data store and optionally allows you to modify it using regular expressions.

Used for passing user specific details such as an email address or a user ID to an internal system

Source name - a drop-down list of fields available in that datastore

Value filter and target - these fields are optional and are used to modify the returned data using a regular expression.

Fixed value

Assigns a fixed value to users in any of the specified categories

Used for things you want to say about lots of users to the majority of SPs such as a scopedAffiliation of ‘member’

Value - the value to be released, e.g. member, staff, or student for eduPersonScopedAffiliation

Service-specific attribute

Similar to a fixed value attribute, but you also have to specify the entityID of the specific SP to release the value to.

Used for passing value to specific SPs, most commonly entitlement attributes but it can also be used for role attributes. The attribute must still be released by policy, but the restriction on the attribute means the policy can release the attribute to all.

Entity ID - the entity ID if the service provider to release this version of the attribute to.

Value - the value to be released, e.g. urn:mace:dir:entitlement:common-lib-terms for eduPersonEntitlement

See also: How to create attributes for specific Service Providers


These are the pseudonymous user IDs that are passed to service providers. The same service provider sees the same ID for the same user every time that user goes back, but a different service provider sees a totally different ID for the same user. You can track your users across resources, but the resources can’t

The salt value forms part of the algorithm that generated the targeted IDs and should not be changed on a live service or your users will be seen as different people by service providers and will lose any saved settings linked to their ID.

Salt value - forms part of the algorithm that generates the targeted ID. This should not be changed on a live service or your users will be seen as different people by service providers and will lose any saved settings linked to their ID

This allows you to use javascript to assign values for situations where the standard attributes cannot work.

Used for potentially anything but an example would be if you needed to pass a role of staff to many SPs instead of only a few – i.e. where the number of service-specific attributes necessary would be unwieldy.

JavaScript - enter code. All attributes defined in the system attributes section are available for use. There are some scripted attribute examples available.


The username the user entered when they logged in. Generally only used as a system attribute.

Used for other parts of the system including providing an element used to generate the targeted ID and logs. This attribute type has no additional fields.

Destination service

This final type is only useful as a system attribute as it makes the entityID of the SP being accessed available. It is of no use as a releasable attribute since the SP being accessed already knows their own entityID.

Used for attribute release policies and scripted attributes. This attribute type has no additional fields.


Just as there are two versions of the targeted ID attribute when you first run OpenAthens LA, you will want to have a second version of the scoped affiliation attribute if you do not already have one. 

This is what you are trying to achieve:

  1. Add a new fixed value attribute and set the fields to be:
    1. Target name: urn:oid:
    2. Friendly name: eduPersonScopedAffiliation
    3. Assigned to category: Everyone
    4. Value: member
  2. Save
  3. Update the friendly name of the existing scopedAffiliation attribute to match

You will also need to release this version of the attribute, but that is covered in the next section.

Next step

Release policies

  • No labels