[Shib-Users] Google Apps cannot parse login request

491 views
Skip to first unread message

Vadnais, Kevin

unread,
Oct 13, 2009, 1:30:16 PM10/13/09
to shibbole...@internet2.edu

Hi all,

 

I’m trying to get the last stage of google apps done for my organization, but have hit a road block once my Idp has authenticated against my LDAP server.  Google apps gives me the following error message once it attempts to redirect after authentication.

 

Google Apps - This account cannot be accessed because we could not parse the login request.

 

My idp log gives no indication of errors, and I’ll include the last bit here below.  From what I see the process authenticated the user correctly, and returned the principal attributes back.  The attribute definitions are also included below.

 

 

Is there a different log I can be looking at to see why Google can’t parse my reply?  I’ve validated that the user/account name exists in google, but whatever I’m sending back doesn’t seem to be of the right format.  Any insight into this would be greatly appreciated.

 

11:10:06.085 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:833] - Building assertion NameID for principal/relying party:kevin.vadnais/google.com

11:10:06.086 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:858] - Relying party 'google.com' supports the name formats: [urn:oasis:saml:tc:SAML:1.1:nameid-format:unspecified]

11:10:06.086 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:554] - Determining if SAML assertion to relying party 'google.com' should be signed

11:10:06.087 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:628] - IdP relying party configuration 'google.com' indicates to sign assertions: false

11:10:06.087 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:635] - Entity metadata for relying party 'google.com 'indicates to sign assertions: false

11:10:06.089 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:524] - Encoding response to SAML request mbjpogdgfaojclkndojbjlcpfobkkmleannbbdpe from relying party google.com

11:10:06.204 - WARN [org.opensaml.saml2.binding.encoding.BaseSAML2MessageEncoder:87] - Relay state exceeds 80 bytes, some application may not support this.

11:10:06.219 - INFO [Shibboleth-Audit:1019] - 20091013T171006Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|mbjpogdgfaojclkndojbjlcpfobkkmleannbbdpe|google.com|urn:mace:shibboleth:2.0:profiles:saml2:sso|https://login.ulethbridge.ca/idp/shibboleth|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_1b83b2d8bd26a99a37da7539846ec1d6|kevin.vadnais|urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport|principal,email,||_92b6a446aa486bff51e7f70cccb7cbfc,|

 

From relying-party.xml

 

<!-- ========================================== -->

    <!--      Metadata Configuration                -->

    <!-- ========================================== -->

    <!-- MetadataProvider the combining other MetadataProviders -->

    <MetadataProvider id="ShibbolethMetadata" xsi:type="ChainingMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata">

   

                <!-- Load the IdP's own metadata.  This is necessary for artifact support. -->

        <MetadataProvider id="IdPMD" xsi:type="ResourceBackedMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata" >

            <MetadataResource xsi:type="resource:FilesystemResource" file="/usr/local/idp/metadata/idp-metadata.xml" />

        </MetadataProvider>

  

        <MetadataProvider

              id="GoogleMD"

              xsi:type="FilesystemMetadataProvider"

              xmlns="urn:mace:shibboleth:2.0:metadata"

              metadataFile="/usr/local/idp/metadata/google-metadata.xml"

              maintainExpiredMetadata="true" />

  

       

        <!-- Example metadata provider. -->

        <!-- Reads metadata from a URL and store a backup copy on the file system. -->

        <!-- Validates the signature of the metadata and filters out all by SP entities in order to save memory -->

        <!-- To use: fill in 'metadataURL' and 'backingFile' properties on MetadataResource element -->

        <MetadataProvider id="URLMD" xsi:type="FileBackedHTTPMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata"

                          metadataURL="http://www.testshib.org/metadata/testshib-providers.xml"

                          backingFile="/usr/local/idp/metadata/testshib.xml">

        </MetadataProvider>

       

    </MetadataProvider>

 

 

From google-metadata.xml

<EntityDescriptor entityID="google.com" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">

                <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

                                <NameIDFormat>urn:oasis:saml:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>

                                <AssertionConsumerService index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

                                                Location="https://www.google.com/a/MY_ORG/acs" />

                </SPSSODescriptor>

</EntityDescriptor>

 

 

From attribute-resolver.xml

 

 

     <resolver:AttributeDefinition

          id="principal"

          xsi:type="PrincipalName"

          xmlns="urn:mace:shibboleth:2.0:resolver:ad">

           

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

 

sdfAnd finally, from the attribute-filter.xml file

 

   

    <AttributeFilterPolicy>

        <PolicyRequirementRule

              xsi:type="basic:AttributeRequesterString" value="google.com" />

        <AttributeRule attributeID="principal">

            <PermitValueRule xsi:type="basic:ANY" />

        </AttributeRule>        

    </AttributeFilterPolicy>

 

 

 

 

Kevin Vadnais

Systems Progammer

University of Lethbridge (IT Department)

403-332-4056

 

There are only 10 kinds of people in this world.  Those that understand binary and those that don't.

 

Vadnais, Kevin

unread,
Oct 13, 2009, 1:55:45 PM10/13/09
to shibbole...@internet2.edu

Hi all,

 

I think I found the problem. 

 

On the webpage https://shibboleth.usc.edu/docs/google-apps/

 

Where the walkthrough for setting up google apps exists, there is an error when specifying the the NAMEID attribute.  The webpage states

 

<resolver:AttributeDefinition id="principal" xsi:type="PrincipalName" xmlns="urn:mace:shibboleth:2.0:resolver:ad">

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

 

However, google only supports the nameFormat of “urn:oasis:saml:tc:SAML:1.1:nameid-format:unspecified”

 

A subtle but important difference.  The clue was in the idp-process.log file when it said

11:10:06.086 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:858] - Relying party 'google.com' supports the name formats: [urn:oasis:saml:tc:SAML:1.1:nameid-format:unspecified]

 

 

 

Thanks all for looking into it for me.

 

Kevin Vadnais

Systems Progammer

University of Lethbridge (IT Department)

403-332-4056

 

There are only 10 kinds of people in this world.  Those that understand binary and those that don't.

 

Scott Cantor

unread,
Oct 13, 2009, 2:22:11 PM10/13/09
to shibbole...@internet2.edu
> However, google only supports the nameFormat of
> "urn:oasis:saml:tc:SAML:1.1:nameid-format:unspecified"

There is no such URI, so if that's true, somebody needs to tell them to fix
this. There is no way that won't continue to trip people up, and they're
asking people to misconfigure their software in order to get it working.

-- Scott


Vadnais, Kevin

unread,
Oct 13, 2009, 2:25:26 PM10/13/09
to shibbole...@internet2.edu
Once I put this into my config, it worked like a dream

Kevin Vadnais
Systems Progammer
University of Lethbridge (IT Department)
403-332-4056

There are only 10 kinds of people in this world. Those that understand
binary and those that don't.

RL 'Bob' Morgan

unread,
Oct 13, 2009, 2:42:09 PM10/13/09
to Shib Users List

>         nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
>
> However, google only supports the nameFormat of
> “urn:oasis:saml:tc:SAML:1.1:nameid-format:unspecified”
>
> A subtle but important difference.  The clue was in the idp-process.log file
> when it said
>
> 11:10:06.086 - DEBUG[edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2Profile
> Handler:858] - Relying party 'google.com' supports the name formats:
> [urn:oasis:saml:tc:SAML:1.1:nameid-format:unspecified]

Hmm, every reference that I can see (via, uh, Google) mentions the URN
that is defined in the SAML 2.0 (and 1.1) spec, that is:

urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

ie, with the "names" in it. Are you saying that your installation can't
sign on to Google with the standard URN but can sign on with the
non-standard one (ie,
urn:oasis:saml:tc:SAML:1.1:nameid-format:unspecified)?

- RL "Bob"

Scott Cantor

unread,
Oct 13, 2009, 3:01:31 PM10/13/09
to shibbole...@internet2.edu
RL 'Bob' Morgan wrote on 2009-10-13:
>> A subtle but important difference. The clue was in the idp-process.log
>> file when it said
>>
>> 11:10:06.086 -
> DEBUG[edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2Pro
> file
>> Handler:858] - Relying party 'google.com' supports the name formats:
>> [urn:oasis:saml:tc:SAML:1.1:nameid-format:unspecified]
>
> Hmm, every reference that I can see (via, uh, Google) mentions the URN
> that is defined in the SAML 2.0 (and 1.1) spec, that is:
>
> urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

Could be that the metadata manually created for the IdP to consume had the error and that google doesn't care. That seems much more likely, I think we'd have heard about this by now.

-- Scott


Vadnais, Kevin

unread,
Oct 13, 2009, 3:19:31 PM10/13/09
to shibbole...@internet2.edu
That's exactly what happened for me. I can flip the light switch so to speak when I change that line in my attribute-resolver.xml file. However, after reading Scott's suggestion, I did find an error in my manually created metadata file in the google-metadata.xml file. Inside there, I saw the incorrect reference for the imaginary URI.

Once again Scott, you have found the needle in the haystack. I guess Google doesn't really care about the format.

Kevin Vadnais
Systems Progammer
University of Lethbridge (IT Department)
403-332-4056

There are only 10 kinds of people in this world. Those that understand binary and those that don't.


Reply all
Reply to author
Forward
0 new messages