Concur V3 configuration and RE: Single Sign On (SSO) no longer working

[Cantor, Scott]

> My chef cookbook has conditional Duo integration.  When Duo is enabled my
> idp.properties has:
> 
> idp.authn.flows= Password|Duo
> idp.authn.flows.initial = Password

Ok, I'm sure that's the reason for the unusual pattern. It just seemed odd, and I didn't remember exactly what it does if you combine that with the donotcache feature. I'd have to trace the code but that explains what the log was saying well enough.

> I did test in both configurations and had same issue.  I can reconstruct the
> non-Duo version fairly quickly if you want me to check what it logs without
> Duo.

Has nothing to do with Duo, I just was confused and realized it had to be the initial flow option involved.

> I am understanding the V3 configuration much better and I really like it.  One
> part that I don't quite get yet is the NameID layout.  I have read all the
> documentation multiple times but I think a high level flow and rational would
> be helpful.  The V2 configuration I inherited had multiple NameID fields
> similar to the Concur example.

I don't know how much more I can say, the new documentation is exhaustive.

> I think that part of the problem is understanding how the IdP determines
> which NameID to use - it seems to want to send the transient ID over any
> others.  Is that because we release the transient ID to all SPs at the top of the
> attribute-filter.xml?

No, and I documented that in so much detail that I can't really see what else I can do. It says exactly how format selection works. It did before, for that matter. 

> Can you provide a pointer to documentation on optional encryption based on
> property?  That sounds really useful.

https://wiki.shibboleth.net/confluence/display/IDP30/SecurityConfiguration#SecurityConfiguration-SigningandEncryptionEnablement

> 1) Adding the V2 style configuration to the attribute-resolver.  For example:

If you're using the old approach for generating NameIDs in the resolver, then you need to follow the V2 documentation, basically.

> 2) Adding the following stanza to the to saml-nameid.xml:

Then you don't need to do it the old way. Pick one. If you do 1 you don't need 2.

> Any suggestions for improvement would be welcome.  I would also be willing
> to make a V3 Concur entry to help others in the future.

1) Pick an approach, old or new. Don't mix them.
2) Never use "unspecified".
3) Never use relying-party.xml to control format selection unless you have to violate (2) or you have to force a selection for an SP you aren't directly loading the metadata for (e.g. something in InCommon).

-- Scott