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

[King, David]

Hi Scott,

Thank you very much for the help today.  It has been very helpful.  

I am very appreciative of the version 3 documentation.  For everything other than NameID I was able to understand its structure quickly from the documentation.    I think a large part of the NameID issue is having seen our V2 configuration first which has a bunch of ... strange things.  That is why I have been trying whenever possible build the replacement the V3 way instead of carrying over these V2 configs any longer.  

I think I have a much better understanding of NameID and will re-read the documentation on it.

Thanks again for the help,
David

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Thursday, March 03, 2016 7:13 PM
To: Shib Users <users at shibboleth.net>
Subject: RE: Concur V3 configuration and RE: Single Sign On (SSO) no longer working

> 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

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net