Clarify SP

Cantor, Scott cantor.2 at osu.edu
Thu Jan 28 19:44:49 EST 2016


On 1/28/16, 3:53 PM, "users on behalf of Robert Lamothe" <users-bounces at shibboleth.net on behalf of robert_lamothe at yahoo.com> wrote:


>
>The answer is yes to both, our configuration page allows us to select InCommon from a list of relying parties.

I'm not 100% sure what that means, so that may not help much. InCommon isn't a relying party, and they could mean lots of different, possibly totally wrong, things by that.

>We're making progress, we can see that the vendor is connecting to our IDP and data is being passed, what isn't clear is why we're failing.  On the diags page under verifications we see "No items were found. If the sign in attempt was successful, the associated user verifications have been deleted."

Obviously that's nothing I can help with.

>One thing we wonder about, the vendor requires PersitentID as an attribute.

That might mean a lot of different things. I can speculate what it might mean, and not much else.

>Based on my reading this is supposed to be generated by the IDP the first time a user connects from a specific SP.

Sort of. It really depends what they're talking about. A SAML 2 Persistent NameID is a pairwise construct and we have extensive documentation in the wiki on the two ways we supply to manage and issue them. One of them is computed, and is not "generated the first time", it's simply generated every time in a consistent way. The other relies on a database, and is generated the first time, yes.

None of that means they're referring to that specific feature. It also may not work if they insist on it being expressed as a SAML Attribute, and that would require different configuration. And I would personally tell them to stuff it and fix their system and just support the standard.

You will find that the number one problem with these integrations is a complete lack of technical precision on the part of the people defining them.

>Do you know of a way to verify that?

The command line aacli tool the IdP provides can debug attribute and NameID behavior, you don't need an SP for that.

If you want to support persistent NameIDs, the documentation is in [1]. If you need to express the same thing as an attribute for the smallish set of possible consumers that might require that, that's a legacy feature that supports the same kind of value generation but with a different configuration approach. I would have to dig up a lot of legacy doc links for that.

-- Scott

[1] https://wiki.shibboleth.net/confluence/display/IDP30/PersistentNameIDGenerationConfiguration



More information about the users mailing list