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:18.104.22.168.4.1.5922.214.171.124.10).
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
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.
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'.
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.
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
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.
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.
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.
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.
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:
- Add a new fixed value attribute and set the fields to be:
- Target name:
- Friendly name:
- Assigned to category:
- Target name:
- 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.