Education vendor SSO configuration requires separate IDP entityIDs for each SP!

Florian Lengyel Florian.Lengyel at cuny.edu
Mon Jan 2 13:50:52 UTC 2023


Thank you for this-very helpful. I'll find an entry point for the vendor.
-Florian

From: Koren, Meshna (ELS-AMS) <M.Koren at elsevier.com>
Sent: Friday, December 23, 2022 10:40 AM
To: Shib Users <users at shibboleth.net>
Cc: Florian Lengyel <Florian.Lengyel at cuny.edu>
Subject: RE: Education vendor SSO configuration requires separate IDP entityIDs for each SP!

Hi Florian,

What a great question you've raised.

As another SP I also think this is a bit of unwanted behaviour. For federated authn to remain scalabale an entityID should represent a meaningful entity, something that a human user can relate to, and not 'an app' that's essentially just a connection between two entities or a configuration set; which is what Okta does. Unfortunately that's indeed not a rule or spelled out anywhere... but it can be seen when one spends 5 minutes looking in the metadata with REFEDS explorer tool:
https://met.refeds.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__met.refeds.org_&d=DwMFAg&c=mRWFL96tuqj9V0Jjj4h40ddo0XsmttALwKjAEOCyUjY&r=w05DwAF0P7ofwV4XZt1zDuW3aSHj2h4ep8o8gzwYbJo&m=jqvkIJB1NySchJN98MdlTIL-w2sMGBQoJzDm7Fg9kbkMGvxMmv1KljUsoQsT9IKp&s=yL-gprwy2cCWlhQFcDeYa9uRZLIUeJEptN-bXwjR9fE&e=>
where each entityIDs also has a recognizable display name.

My suggestion would be to ask the SP to take time and review AARC blueprint architecture:
https://aarc-community.org/architecture/<https://urldefense.proofpoint.com/v2/url?u=https-3A__aarc-2Dcommunity.org_architecture_&d=DwMFAg&c=mRWFL96tuqj9V0Jjj4h40ddo0XsmttALwKjAEOCyUjY&r=w05DwAF0P7ofwV4XZt1zDuW3aSHj2h4ep8o8gzwYbJo&m=jqvkIJB1NySchJN98MdlTIL-w2sMGBQoJzDm7Fg9kbkMGvxMmv1KljUsoQsT9IKp&s=1Gryex_CKeQcSKMekhKQ8MFiqC62C_jIXkuhZnbBCow&e=>
(and the metadata explorer tool) with a note that this is how most of academic community uses federated authn today; this system offers a lot of opportunities such as Seamless Access etc from which the SP will undoubtedly benefit in more than one way.

I don't know what's the best starting point, though.

Kind regards,
Meshna



Meshna Koren

Product Manager II
Product Management, Identity

Elsevier BV
Radarweg 29, Amsterdam 1043 NX, The Netherlands
m.koren at elsevier.com<mailto:m.koren at elsevier.com>

Federated Access - SAML, Shibboleth, Corporate SSO, OpenAthens, Institutional Login

Elsevier Access Support Center: https://service.elsevier.com/app/home/supporthub/elsevieraccess/<https://urldefense.proofpoint.com/v2/url?u=https-3A__service.elsevier.com_app_home_supporthub_elsevieraccess_&d=DwMFAg&c=mRWFL96tuqj9V0Jjj4h40ddo0XsmttALwKjAEOCyUjY&r=w05DwAF0P7ofwV4XZt1zDuW3aSHj2h4ep8o8gzwYbJo&m=jqvkIJB1NySchJN98MdlTIL-w2sMGBQoJzDm7Fg9kbkMGvxMmv1KljUsoQsT9IKp&s=95pdzqaM-4SOjc8yhQcjk5a48V-kXw4_Rbb6JeJnETo&e=>
for your questions about which access methods does Elsevier support, how to set them up, how do they work for users...




From: users <users-bounces at shibboleth.net<mailto:users-bounces at shibboleth.net>> On Behalf Of Florian Lengyel via users
Sent: Thursday, December 22, 2022 01:43
To: Shib Users <users at shibboleth.net<mailto:users at shibboleth.net>>
Cc: Florian Lengyel <Florian.Lengyel at cuny.edu<mailto:Florian.Lengyel at cuny.edu>>
Subject: RE: Education vendor SSO configuration requires separate IDP entityIDs for each SP!


*** External email: use caution ***


My suspicion was that this particular service provider was using Okta-this is now confirmed. In my experience,
some SP developers who use Okta have the impression that each SP must have its own distinct IDP metadata-the
metadata cannot be the same.  I was able to disabuse one vendor of this misapprehension. However, the latest vendor
has designed an SP that somehow assigns a so-called OPID to the entityID of the IDP (not kidding!), instead of relying an
attribute such as eduPersonScopedAffiliation in the SAML response to the SP-or something sensible.

Scott Cantor's response was very helpful, by the way. This is something I can send up the flagpole.
I guess he's seen everything. I'm still capable of being nonplussed-not to mention flabbergasted.

-F


From: users <users-bounces at shibboleth.net<mailto:users-bounces at shibboleth.net>> On Behalf Of Spencer Thomas via users
Sent: Wednesday, December 21, 2022 5:27 PM
To: Shib Users <users at shibboleth.net<mailto:users at shibboleth.net>>
Cc: Spencer Thomas <Spencer.Thomas at ithaka.org<mailto:Spencer.Thomas at ithaka.org>>
Subject: Re: Education vendor SSO configuration requires separate IDP entityIDs for each SP!

***ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails.***

And when I said eduPersonEntitlement, I actually meant eduPersonScopedAffiliation.

On 12/21/22, 2:12 PM, "users" <users-bounces at shibboleth.net<mailto:users-bounces at shibboleth.net>> wrote:

[cid:image001.gif at 01D91E87.4FE8B7D0]
As a service provider, I can say that we have definitely engineered our SP to accommodate multiple institutions using the same EntityID. We obviously require a different attribute, most typically eduPersonEntitlement, to distinguish between those institutions.

--
Spencer Thomas
Technical Architect
ITHAKA<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam11.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Fwww.ithaka.org-5F-2526d-253DDwMF-2Dg-2526c-253DmRWFL96tuqj9V0Jjj4h40ddo0XsmttALwKjAEOCyUjY-2526r-253Dw05DwAF0P7ofwV4XZt1zDuW3aSHj2h4ep8o8gzwYbJo-2526m-253DFUytUOszF6u1h8HnN-2DDI-5FKv6s8vLU5eCFdhIJBFjVOa-2DJxl0iyomlKsYqEnOpRmE-2526s-253DyA6pvruWzOEpvdkwsi93VD2ROpHBPWlwbuAGWtFbcaY-2526e-253D-26data-3D05-257C01-257CM.Koren-2540elsevier.com-257Cf67c24b06f5a4c37019408dae3b5822a-257C9274ee3f94254109a27f9fb15c10675d-257C0-257C0-257C638072666408236143-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-257C-257C-257C-26sdata-3DxLi1w2e1udcuc3Kwz7xGgmhZSeuqdOo0ajkq6jRqOZo-253D-26reserved-3D0&d=DwMFAg&c=mRWFL96tuqj9V0Jjj4h40ddo0XsmttALwKjAEOCyUjY&r=w05DwAF0P7ofwV4XZt1zDuW3aSHj2h4ep8o8gzwYbJo&m=jqvkIJB1NySchJN98MdlTIL-w2sMGBQoJzDm7Fg9kbkMGvxMmv1KljUsoQsT9IKp&s=OZ3kdU3_4Thv7D8cD6FHtr09KipZKy25zR9APveMxmc&e=>
301 E. Liberty St, Suite 250, Ann Arbor, MI 48104
Email: Spencer.Thomas at ithaka.org<mailto:Spencer.Thomas at ithaka.org>
Voicemail: +1-734-887-7004
ithaka.org<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam11.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Fwww.ithaka.org-5F-2526d-253DDwMF-2Dg-2526c-253DmRWFL96tuqj9V0Jjj4h40ddo0XsmttALwKjAEOCyUjY-2526r-253Dw05DwAF0P7ofwV4XZt1zDuW3aSHj2h4ep8o8gzwYbJo-2526m-253DFUytUOszF6u1h8HnN-2DDI-5FKv6s8vLU5eCFdhIJBFjVOa-2DJxl0iyomlKsYqEnOpRmE-2526s-253DyA6pvruWzOEpvdkwsi93VD2ROpHBPWlwbuAGWtFbcaY-2526e-253D-26data-3D05-257C01-257CM.Koren-2540elsevier.com-257Cf67c24b06f5a4c37019408dae3b5822a-257C9274ee3f94254109a27f9fb15c10675d-257C0-257C0-257C638072666408236143-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-257C-257C-257C-26sdata-3DxLi1w2e1udcuc3Kwz7xGgmhZSeuqdOo0ajkq6jRqOZo-253D-26reserved-3D0&d=DwMFAg&c=mRWFL96tuqj9V0Jjj4h40ddo0XsmttALwKjAEOCyUjY&r=w05DwAF0P7ofwV4XZt1zDuW3aSHj2h4ep8o8gzwYbJo&m=jqvkIJB1NySchJN98MdlTIL-w2sMGBQoJzDm7Fg9kbkMGvxMmv1KljUsoQsT9IKp&s=OZ3kdU3_4Thv7D8cD6FHtr09KipZKy25zR9APveMxmc&e=>
[ITHAKA logo]


On 12/21/22, 1:32 PM, "users" <users-bounces at shibboleth.net<mailto:users-bounces at shibboleth.net>> wrote:

Caution: This message did not originate from within ITHAKA's email system. Please use caution when opening attachments and following links within this message.
[cid:image001.gif at 01D91E87.4FE8B7D0]
Hi,

I'm writing from the City University of New York. We're attempting to enable SAML2 SSO with
a vendor who would configure a service provider instance for each of our 26 campuses-except
for one problem that I have never encountered in my years of configuring Shibboleth.

Their system will not accept the same IDP entity ID for two or more SPs. We have one SP instance
configured in their system  (and in ours as a relying party) with our IDP metadata (we're running IDP 4.0.1).
This integration works as expected. When they attempt to configure a new SP instance, their system
generates the error message, "Duplicate IDP Entity ID. Another IDP profile has the same Entity ID."

Am I correct that this constraint on IDP and SP entityIDs is nonstandard?

In case I have made an unwarranted assumption about their system, the SAML2 specification or both, is there
a way to generate separate metadata for the same IDP with different entityIDs? One of their customers
(another university) provided the vendor with IDP metadata of the form entityID=constantURL?variableID=theID.
The ACS etc endpoints in their metadata also contained the additional argument. I do not know if this customer stood
up separate IDPs.

I feel as though I ought to apologize for this.


Sincerely,

Florian



[cid:image003.png at 01D91E87.4FE8B7D0]
Florian Lengyel, PhD
Identity and Access Management
CUNY CIS 395 Hudson Street, New York, NY 10014
Voicemail: (646) 664-2370 Cell: (917) 621-7845
Email: florian.lengyel at cuny.edu<mailto:florian.lengyel at cuny.edu>


________________________________

Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33158992, Registered in The Netherlands.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20230102/83fa9b4c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 92 bytes
Desc: image001.gif
URL: <http://shibboleth.net/pipermail/users/attachments/20230102/83fa9b4c/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1425 bytes
Desc: image002.png
URL: <http://shibboleth.net/pipermail/users/attachments/20230102/83fa9b4c/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 3894 bytes
Desc: image003.png
URL: <http://shibboleth.net/pipermail/users/attachments/20230102/83fa9b4c/attachment-0001.png>


More information about the users mailing list