Scope matching
Keystone checks attributes that should have a scope to make sure that:
there actually is a scope, and
the scope is in the list declared in the IdP’s metadata
If either condition is not met, then the attribute is not passed on to your application.
These are the attributes that get checked:
Attribute ‘friendly’ name | SAML attribute name | Example |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The first three are the most likely to be sent. Even though the scoped format may resemble an email address (especially EduPersonPrincipalName), they shouldn’t be treated as such.
What if I need to turn this off or make adjustments?
Our scope check is on or off for all, and you can toggle that in the SAML section of your connection.
If you need to fine tune things to allow for specific customer needs, there’s a rule you can turn on that will make the IdPs scoped values available in a claim so that you can do your own checks instead of ours.
My friend isn’t sure what a scope is...
With SAML and similar, it’s scope as in the belonging to, purview of, sphere, breadth, etc, of an organisation.
The attributes that include this scope are termed ‘scoped’, and what it looks like is a bit like an email address - e.g. member@example.com. In this example, it is the example.com bit that is the scope.
It is, strictly speaking, the scope(s) you should authorise on rather than the entiyID since the scope is the organisation identifier (the entityID is just the identifier of the metadata).