A federated customer is likely to tell you up front what their federation entityID and scope are. They will look like this:
- EntityID -
- Scope - theirdomain.net
They will be used to this being sufficient information for federated suppliers (which you will appear to be thanks to OpenAthens Keystone).
Their entityID will appear under the standard claim '
realmName', but might represent a consortium of organisations so you should expect to map read their scope to a claim you use in your authorisation process. You might accomplish this by:
Enabling the EduPerson ruleset and authorising on the eduPersonScopedAffiliation claim it produces
- Creating your own mapping rule.
from the claim '
derivedEduPersonScope' for authorisation decisions.
They may also ask if there are any other attributes you need them to release, or that might improve the user experience. They will be able to release them under whatever name you choose, however it will be easiest for them to use the standard attribute names in their federation - e.g. most members of the OpenAthens federation will easily be able to use forenames, surname and emailAddress. You would just need to set up the mapping in a ruleset. That said, you will find that most are reluctant to release personally identifiable information to you so you should not make anything rely on those claims being passed