Google Apps with IdP v3 not working

David Langenberg davel at uchicago.edu
Wed Aug 26 10:57:38 EDT 2015


Here's our setup for Google & service-now:

relying-party.xml

<bean id="r31" parent="RelyingPartyByName"
                    c:relyingPartyIds="#{{'google.com',
                                  'uchicago.maps.arcgis.com',
                                  'https://uchicagosandbox.service-now.com',
                                  'https://uchicagotest.service-now.com',
                                  'https://uchicagodev.service-now.com',
                                  'https://uchicago.service-now.com',
                                  'https://uofccalgarypov.service-now.com',
                                  'https://ucmeddev.service-now.com',
                                  'https://ucmedtest.service-now.com',
                                  'https://ucmctraining.service-now.com',
                                  'https://ucmed.service-now.com'}}">
            <property name="profileConfigurations">
                <list>
                    <bean id="b31" parent="SAML2.SSO"
                            p:postAuthenticationFlows="context-check"
                            p:encryptAssertions="false"
                            p:includeAttributeStatement="false"
                            p:signAssertions="false"
                            p:encryptNameIDs="false"
                            p:nameIDFormatPrecedence="#{{'urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified'}}" />
                </list>
            </property>
        </bean>

saml-nameid.xml

 <util:list id="shibboleth.SAML2NameIDGenerators">
    
        <ref bean="shibboleth.SAML2TransientGenerator" />
        
        <!-- Uncommenting this bean requires configuration in saml-nameid.properties. -->
        <!--
                     <ref bean="shibboleth.SAML2PersistentGenerator" />
        -->

        <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
            p:format="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"
            p:attributeSourceIds="#{ {'principal','ucStudentID1'} }" />
        
        <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
            p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
            p:attributeSourceIds="#{ {'mailNameId' } }" />
        
                
    </util:list>

attribute-resolver.xml

    <resolver:AttributeDefinition id="principal" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
                                  sourceAttributeID="uid">
        <resolver:Dependency ref="directory"/>
        <resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                                   name="urn:oid:1.3.6.1.4.1.9902.2.1.9" friendlyName="principal" />
    </resolver:AttributeDefinition>

Dave


> On Aug 26, 2015, at 7:00 AM, Dave Perry <Dave.Perry at hull-college.ac.uk> wrote:
> 
> Hi Michael
> 
> I tried uncommenting the 'old' NameID generators in saml-nameid.properties, uncommenting the beans in the .xml file, and specifying (in the .properties file):
> idp.persistentId.generator = shibboleth.SAML2AttributeSourcedGenerator
> 
> And added the unspecified name format bean 'fix' from that wiki page into relying-party.xml.
> 
> Nothing worked, and in fact it broke the nameid generation so we couldn't access any other SPs - so I had to give up and just disable the 'old' name generators again.
> 
> Has anyone who's got this working got a complete set of config changes list/code they'd be willing to share? It means that, for now, I have to tell google to SSO using our v2 IdP (which I know isn't EOL yet, but I want this sorted sooner rather than later).
> It really doesn't help that google won't let me try pairing up 2 IdPs, so I can migrate from one to the other with a testing period, without interrupting live users.
> 
> 
> Thanks,
> Dave
> _________________________________________________
> Dave Perry
> eLearning Technologist, Hull College Group
> 
> Room L34 - Queens Gardens Library
> Wilberforce Drive, Queen's Gardens, Hull, HU1 3DG
> Extension 2230 / Direct Dial 01482 381930
> 
> * Need a fast reply? Try elearning at hull-college.ac.uk *
> 
> 
> -----Original Message-----
> From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Domingues, Michael D
> Sent: 20 August 2015 14:46
> To: Shib Users
> Subject: RE: Google Apps with IdP v3 not working
> 
> Hi Dave,
> 
> Is this an entirely new IdPv3 deployment, on an in-place upgrade of an existing v2 instance? I suspect the former, but wanted to clarify first.
> 
> Between IdPv2 and IdPv3, the default way that NameID generation works has been changed [1]. If I'm understanding this correctly, to enable the legacy v2-style config that you've included below, if you haven't performed an in-place upgrade, you'll need to uncomment a couple of properties in saml-nameid.properties file.
> 
> See the section titled "V2 Compatibility" in the aforementioned doc for more information.
> 
> [1] https://wiki.shibboleth.net/confluence/display/IDP30/NameIDGenerationConfiguration
> 
> Best,
> Michael Domingues
> Systems Administrator
> Directory and Authentication Services, AIS, ITS University of Iowa
> 
> -----Original Message-----
> From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Dave Perry
> Sent: Thursday, August 20, 2015 4:46 AM
> To: users at shibboleth.net
> Subject: Google Apps with IdP v3 not working
> 
> I have copy/pasted my Idp v2 settings over to the v3 attribute-resolver and attribute-filter config files, and amended the URL Google Apps tries to interact to our IdP with, and it clearly doesn’t work. I get the following error when hitting drive.google.com/a/ourdomain:
> 
> Google Apps - This account cannot be accessed because your credentials were not verified.
> This account cannot be accessed because your credentials were not verified.
> We are unable to process your request at this time, please try again later.
> 
> 
> I thought it was the certificate I generated, as per google's instructions (both the DSA and RSA attempts gave the above result). Google’s rep told me on live chat:
> “From what I can tell Dave this error does not seem to have an issue with the certificat​e itself, but the redirectio​n of how the SSO is incorrect because it does not seem to accept your credential​s. I'm really not sure where it's redirectin​g or what exactly is happening“
> 
> Here is my v2 config:
> [filter]
> <!--google apps-->
> 	<!--from Andy on mailing list:-->
> 	<afp:AttributeFilterPolicy id="google-principal">
>         <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="google.com" />
>         <afp:AttributeRule attributeID="g_principal">
>             <afp:PermitValueRule xsi:type="basic:ANY" />
>         </afp:AttributeRule>
>     </afp:AttributeFilterPolicy>
> 
> [resolver]
> <!--google apps signin (from v2 config)-->
> 	<resolver:AttributeDefinition xsi:type="ad:Simple" id="g_principal" sourceAttributeID="mail">
>         <resolver:Dependency ref="myLDAP" />
>         <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>
>     </resolver:AttributeDefinition>
> 
> On the Google SSO settings I have sign-in page URL = https://idprealworldurl/idp/profile/SAML2/Redirect/SSO (same as it was for v2, I just changed idprealworld as it's a slightly different address now).
> 
> Any pointers appreciated.
> 
> Thanks,
> Dave
> _________________________________________________
> Dave Perry
> eLearning Technologist, Hull College Group
> 
> Room L34 - Queens Gardens Library
> Wilberforce Drive, Queen's Gardens, Hull, HU1 3DG Extension 2230 / Direct Dial 01482 381930
> 
> * Need a fast reply? Try elearning at hull-college.ac.uk *
> 
> 
> **********************************************************************
> This message is sent in confidence for the addressee only. It may  contain confidential or sensitive information.  The contents are not to be disclosed to anyone other than the addressee.  Unauthorised recipients are requested to preserve this confidentiality and to advise us of any errors in transmission.  Any views expressed in this message are solely the views of the individual and do not represent the views of the College.  Nothing in this message should be construed as creating a contract.
> 
> Hull College Group owns the email infrastructure, including the contents.
> 
> Hull College Group is committed to sustainability, please reflect before printing this email.
> **********************************************************************
> 
> TEXT
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

--
David Langenberg
Identity & Access Management Architect
The University of Chicago





More information about the users mailing list