Skip to main content
Skip table of contents

Scope checking

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

eduPersonScopedAffiliation 

urn:oid:1.3.6.1.4.1.5923.1.1.1.9 

member@example.com

eduPersonPrincipalName 

urn:oid:1.3.6.1.4.1.5923.1.1.1.6 

bob.roberts@example.com

Pairwise-ID 

urn:oasis:names:tc:SAML:attribute:pairwise-id 

OWI3YCR14MOJA8OGKJEN5TGWN=@example.com

eduPersonUniqueId 

urn:oid:1.3.6.1.4.1.5923.1.1.1.13 

dlkaghruh788ag7ro8agr@example.com

Subject-ID 

urn:oasis:names:tc:SAML:attribute:subject-id 

fh834r-8yPFHYEw@example.com

The first three are the most likely to be sent. EduPersonPrincipalName isn’t an email address either.

I'm not sure what a scope is though...

Some attributes are 'scoped', which means they have an organisation identifier included. This makes them look a bit like an email address - e.g. member@example.com - 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.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.