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.
Attributes that are 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 IdP's scoped values available in a claim so that you can do your own checks instead of ours.
What is a scope?
With SAML and similar, it’s scope as in the belonging to, purview of, sphere, breadth, etc, of an organization.
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 authorize on rather than the entityID since the scope is the organization identifier (the entityID is just the identifier of the metadata).