Production IdP is providing attributes with inconsistent scopes.

[emetsger]

test.digital.library.jhu.edu (a Drupal-based system) supports SAML logins using the SimpleSAMLphp service provider. Users are created in Drupal by SimpleSAMLphp with the end-user's eduPersonPrincipalName (eppn) attribute from the IdP.

You can see in the screenshot below that there are two different eppn scopes being provided by the IdP: @jh.edu and @johnshopkins.edu. Upon closer examination, you'll see that there are duplicate user accounts as well:

• bseeger1@jh.edu and bseeger1@johnshopkins.edu are the same person, but the scopes differ
• abirkla1@jh.edu and abirkla1@johnshopkins.edu are the same person, but the scopes differ

The screenshot was captured today (11/30/21). Looking at the dates you can see that this is an ongoing problem:

• abirkla1@johnshopkins.edu was created 6 weeks ago, and the duplicate abirkla1@jh.edu was created two weeks ago.
• bseeger1@johnshopkins.edu was created two weeks ago, and the duplicate bseeger1@jh.edu was created today, just moments ago.

The eppn for a user should not change - at least the scope should be the same within the federation (I'm not sure what the policies are for eppn with respect to a name change). My understanding (which needs to be confirmed) is that the SimpleSAMLphp SP is participating in the "Blue Jay" federation.

Can IT@JH confirm that all IdPs in the Blue Jay federation issue attributes with a consistent scope, and can they confirm the scope: jh.edu or johnshopkins.edu?

The IDC meeting agenda minutes are located here.

[emetsger]

Another data point: below is the screenshot from the SimpleSAMLphp for my eppn emetsge1@jh.edu. Note that the IdP is providing attributes with a mix of scopes:

• eduPersonUniqueId is @johnshopkins.edu
• eduPersonPrincipalName is @jh.edu
• eduPersonScopedAffiliation is @johnshopkins.edu

[jhujasonw]

I have gotten a reply from IT@JH:

" Is this drupal instance using the Shibboleth SP software in conjunction with it? If it is, would it be possible to get a copy of the attribute-map.xml file?

I have a feeling there is a duplicate entry or something in conflict. The IdP will only return @johnshopkins.edu for the eduPersonPrincipalName. That attribute is defined as the jhed@johnshopkins.edu on the IdP:

<AttributeDefinition xsi:type="Scoped" id="eduPersonPrincipalName" scope="johnshopkins.edu">

    <InputDataConnector ref="win" attributeNames="samaccountname" />

    <AttributeEncoder xsi:type="SAML1ScopedString" name="urn:mace:dir:attribute-def:eduPersonPrincipalName" />

    <AttributeEncoder xsi:type="SAML2ScopedString" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" friendlyName="eduPersonPrincipalName" />

</AttributeDefinition>

The userprincipalname will always be jhed@jh.edu, but there is no way the eppn is coming as @jh.edu and I am unable to replicated that behavior. "

[emetsger]

Another data point:

I logged in to test.digital.library.jhu.edu just now, and note my eppn is @johnshopkins.edu (compared to @jh.edu) from ~ 1 week ago.

[emetsger]

@jhujasonw can you provide the following files - from test.digital - (I think these are relative to /var/www/drupal) and attach them to this issue (you can redact sensitive keys if you wish, but otherwise please leave the files as-is):

• vendor/simplesamlphp/simplesamlphp/metadata/saml20-idp-remote.php
• vendor/simplesamlphp/simplesamlphp/config/config.php
• vendor/simplesamlphp/simplesamlphp/config/authsources.php
• vendor/simplesamlphp/simplesamlphp/config/acl.php

Thanks!

[jhujasonw]

I've sent you a place to obtain those files out of band.

[emetsger]

@jhujasonw thanks for providing those files. The string @jh.edu does not exist in any of the configuration files, and it does not exist in the module code base. So if there is any interaction with SimpleSAMLphp munging attribute scopes, it is beyond me how that would be happening. IT@JH may wish to see these files, as they provide not only the attribute mapping, but also specifies IDP metadata and other SAML-related settings.

The only other straw I can grasp at is the environment: can you provide a dump of the environment?

At this juncture, it it may make sense for IT@JH to login to test.digital and see if they can re-create the issue. For example, have them login and visit https://test.digital.library.jhu.edu/simplesaml/module.php/core/authenticate.php?as=default-sp, and view their attributes and see if they can trigger the behavior. This may require them to retry multiple times, completely closing down their browser after each attempt to clear out any state.

[jhujasonw]

Sent the env to @emetsger out of band

[emetsger]

@jhujasonw I took a look, I didn't see anything in the environment that would affect this issue.