"This account cannot be accessed because we could not parse the login request" message

[Brian Jimerson]

I've seen this error posted several times before and have check my
SAML response against the issues pointed out. But it seems like the
SAML response I have is valid.

I have a SAML 2.0 IdP configured for SSO with Google Apps. I have
tested the SAML response and signing against a simplesamlphp sp and it
works fine, but every time I try it with my google apps domain, I get
this message: This account cannot be accessed because we could not
parse the login request.

The SAML response is below (the issuant and validity periods are valid
for when the response was created). Does anything see anything that
may be causing this issue?

============= SAML Response ========================

<?xml version="1.0" ?>
<saml2p:Response Destination="https://www.google.com/a/onedrumroll.com/
acs" ID="9c7f97cf-ef44-4217-92d1-96be03c6323c"
IssueInstant="2012-02-16T02:50:23.866Z" Version="2.0"
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xs="http://
www.w3.org/2001/XMLSchema">
<saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-
format:entity" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
http://sso.idp.com/
</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/
xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/
xmldsig#rsa-sha1"/>
<ds:Reference URI="#9c7f97cf-ef44-4217-92d1-96be03c6323c">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/
xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-
c14n#">
<ec:InclusiveNamespaces PrefixList="xs" xmlns:ec="http://
www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/
xmldsig#sha1"/>
<ds:DigestValue>
MCDE4QIJaENC2ATuJ0hV+UbgsjM=
</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
MpfsEAw4CF3jMbjKz6i62X8NLjE/HKLTfzH1DcMdMuSUflfUR00d/5eGOgyCpc/
BsXyVnENqTBdLYEZ9UEVvF0zhoXxA8iWL69SxzA5Tb789EWBb6ECrLTMSZ8BxeqRj4m5cdsE9Yk2jARN4SMyvzDXbfSGsX11Hq4e5ROWzTww=
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>

MIICfTCCAeagAwIBAgIETzMTzTANBgkqhkiG9w0BAQUFADCBgjELMAkGA1UEBhMCVVMxDTALBgNV
BAgTBE9oaW8xFDASBgNVBAcTC1ZhbGxleSBWaWV3MRYwFAYDVQQKEw1BdmFudGlhLCBJbmMuMRIw
EAYDVQQLEwlBZG1pdFNhZmUxIjAgBgNVBAMTGWh0dHA6Ly9zc28uYWRtaXRzYWZlLmNvbS8wHhcN
MTIwMjA5MDAzMTA5WhcNMTcwMjA4MDAzMTA5WjCBgjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE9o
aW8xFDASBgNVBAcTC1ZhbGxleSBWaWV3MRYwFAYDVQQKEw1BdmFudGlhLCBJbmMuMRIwEAYDVQQL
EwlBZG1pdFNhZmUxIjAgBgNVBAMTGWh0dHA6Ly9zc28uYWRtaXRzYWZlLmNvbS8wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBANUJMlw8K1cwKnUXC5KK8KB3szXKLlxUBNimJcI05BJ6EKV7YZxt
4ChA4KVz6KhNSr3sVBPynf1zSneIdjPUGr91F71V27okD9WhWn7CK260eudLfeq2FRqPXBSlnRrE
zDBlGvRf8AONpSR4kfEfiw94Ka2lZN11PmoI1KrYAVsFAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEA
amDQydLTsxjor0grDagA0dnAvYDy/LOy6gvgVY2qkub
+1pnKZRdv2SqijbgSv5isyBbkfLHS1zD0
Tbzl7hUTNoeWQijgkxE3ddgTWWt0Ly4iuAFs2VeLGxIb
+p3jM17Yq9xqXkOMOTyQwrltujhFihGu Fvhy4D9z+3ACvwFPR8I=
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:
2.0:status:Success"/>
</saml2p:Status>
<saml2:Assertion ID="0ce76556-81cf-46c2-986f-ec9c8239fdb0"
IssueInstant="2012-02-16T02:50:23.865Z" Version="2.0"
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
<saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-
format:entity">
http://sso.idp.com/
</saml2:Issuer>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-
format:emailAddress">
bjim...@avantia-inc.com
</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:
2.0:cm:bearer">
<saml2:SubjectConfirmationData Address="0:0:0:0:0:0:0:1%0"
InResponseTo="fkbjjjjfieeomppokeicjmcgmegemlfgfijpdkng"
NotOnOrAfter="2012-02-16T02:50:23.860Z" Recipient="https://
www.google.com/a/onedrumroll.com/acs"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:AuthnStatement AuthnInstant="2012-02-16T02:50:23.590Z">
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:Password
</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
<saml2:AttributeStatement>
<saml2:Attribute Name="granted_authorities"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
</saml2:AttributeStatement>
</saml2:Assertion>
</saml2p:Response>

============= SAML Response ========================

Thanks in advance.

Brian

[Jack]

Possibly the certs need to be reloaded? That has happened to me at times

Hope that helps.

> --
> You received this message because you are subscribed to the Google Groups "SAML-based Single Sign On for Google Apps" group.
> To post to this group, send email to google-app...@googlegroups.com.
> To unsubscribe from this group, send email to google-apps-saml...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-apps-saml-sso?hl=en.
>

[T1B0]

I'll spare you two weeks of errands and random trials, XML ID MUST BEGIN WITH A LETTER !
I had a random ID generator so in my case it would work or not based on pure randomness ...
Oh yeah thanks OASIS again for their poorly written specs (re-read that saml id part, it's totally misleading),
 and thx google for being the only one to enforce this rule ...

Hope this'll help !

[Tom Scavo]

On Thu, Feb 16, 2012 at 9:38 AM, T1B0 <t1b...@gmail.com> wrote:
>
> I'll spare you two weeks of errands and random trials, XML ID MUST BEGIN
> WITH A LETTER !

Actually, the first character must be a letter or underscore.

> I had a random ID generator so in my case it would work or not based on pure
> randomness ...
> Oh yeah thanks OASIS again for their poorly written specs (re-read that saml
> id part, it's totally misleading)

Well, the ID attribute belongs to the XML Schema spec, not the SAML spec.

>  and thx google for being the only one to enforce this rule ...

That's not true at all. Any software that conforms to the spec will
enforce of this requirement. (Shibboleth, for example, enforces this.)

Tom

[Brian Jimerson]

OK, so I made sure that the ID attribute on the saml response and
assertion elements always start with a letter, but still get the same
results. I also regenerated and reloaded the signing cert. Anyone have
any other thoughts?

Brian

On Feb 16, 7:05 am, Tom Scavo <trsc...@gmail.com> wrote:

[rohit.t...@resilient-networks.com]

Brian -- I'm running into the same issue. Were you ever able to fix this?

[A2 Support]

I am also facing the same issue. Does anyone know what is the root cause of it?