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

[King, David]

Hi 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

Once I realized the problem I disabled the Duo integration which switched the idp.properties to:

idp.authn.flows= Password
#idp.authn.flows.initial = Password

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.

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 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?

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

Thanks,
David

PS: This is how I adapted the V2 Concur setup to our V3 system.  Once we are past the first release I am going to try and clean it up starting with Scott's comments about the unspecified name and editing the Concur metadata.  I got it to work by:

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

    <resolver:AttributeDefinition id="scopedPrincipalNameID" xsi:type="Simple" sourceAttributeID="eduPersonPrincipalName"
        xmlns="urn:mace:shibboleth:2.0:resolver:ad">
        <resolver:Dependency ref="myLDAP" />
        <resolver:AttributeEncoder xsi:type="SAML2StringNameID" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
            nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" />
    </resolver:AttributeDefinition>

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

        <bean parent="shibboleth.SAML1AttributeSourcedGenerator"
            p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
            p:attributeSourceIds="#{ {'principalNameIDuppercased','scopedPrincipalNameID'} }" />

3) Adding the following bean to relying-party.xml to give precedence to that particular nameid (that one in the SAML1NameIdentifiers):

      <bean parent="RelyingPartyByName"
          c:relyingPartyIds="#{ {
            'https://www.fieldglass.net',
            'https://www.concursolutions.com'
          } }">
          <property name="profileConfigurations">
            <list>
              <bean parent="SAML2.SSO"
                p:signAssertions="always"
                p:encryptAssertions="false"
                p:encryptNameIDs="false"
                p:nameIDFormatPrecedence="#{{'urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified'}}"
                />
            </list>
          </property>
        </bean>

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

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

> I eventually found the problem and it now makes sense.  The work to 
> customize the interface had resulted in setting the donotcache flag on 
> username/password input.  So that sequence of messages indicates that 
> donotcache is set.  Anyway, the problem is fixed.

Hmm. Do you have the initial-authn feature in use? I wouldn't expect it to be able to log a reuse a Password result like that if donotcache were set...even with that feature it seems off to me, but that's the only plausible case I can think of.

> As for Concur, this is a configuration that I inherited which appears 
> to be based on an IdP v2 entry in the wiki.  Does someone have a 
> simpler v3 configuration?  The config I inherited has a few NameID special cases:
> Concur, FieldGlass (using a scoped attribute ID with a SAML1 
> encoding), and Ariba (uppercased username).

It's not a V3 thing, it's just a fact that Concur doesn't care what Format you use in the NameID, so you don't need to use "unspecified".

NameID selection should be driven by metadata when possible, and since you have to invent Concur's metadata locally anyway, you just put NameIDFormat into it with the format you choose to configure. That should never be "unspecified".

In V2 you would still need to override a RP definition to turn encryption off. In V3 you can eliminate that step by making encryption optional with a property and not touch relying-party.xml at all

-- Scott

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