Invalid SPNameQualifier for this request
It Meme
I have been following University of Chicago's notes on Shibboleth
integration with Service Now (IdP v2.2):
https://docs.google.com/document/d/1yApSgHn0C02z09zYC3CD_edX7s3DbnuGgJ-kI-BhqYI/edit?hl=en_US&authkey=CPK1ppQN&pli=1
We are receiving a 'Invalid SPNameQualifier for this request' status
value in our IdP process logs - any guidance on what could have
triggered this?
<?xml version="1.0" encoding="UTF-8"?><saml2p:Response
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
Destination="https://xxxx.service-now.com/navpage.do"
ID="_d2d226646517c2cf1a10f951e52c4aa5"
InResponseTo="SNC5807eb61f80bab461c721f50878a4cab"
IssueInstant="2011-09-08T23:33:45.010Z" Version="2.0">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://example.com/idp/shibboleth</saml2:Issuer>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester">
<saml2p:StatusCode
Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy"/>
</saml2p:StatusCode>
<saml2p:StatusMessage>Invalid SPNameQualifier for this
request</saml2p:StatusMessage>
</saml2p:Status>
</saml2p:Response>
--
To unsubscribe from this list send an email to users-un...@shibboleth.net
Cantor, Scott
>
>We are receiving a 'Invalid SPNameQualifier for this request' status
>value in our IdP process logs - any guidance on what could have
>triggered this?
An invalid SPNameQualifier in the NameIDPolicy element of the request.
-- Scott
David Langenberg
> Hi:
>
> I have been following University of Chicago's notes on Shibboleth
> integration with Service Now (IdP v2.2):
> https://docs.google.com/document/d/1yApSgHn0C02z09zYC3CD_edX7s3DbnuGgJ-kI-BhqYI/edit?hl=en_US&authkey=CPK1ppQN&pli=1
>
> We are receiving a 'Invalid SPNameQualifier for this request' status
> value in our IdP process logs - any guidance on what could have
> triggered this?
This error is triggered from some kind of monitoring process at
service-now. It's really annoying and we've filed several bugs on it,
but haven't seen a resolution yet.
Dave
--
================================
David Langenberg
Identity Management
The University of Chicago
================================
Cantor, Scott
>
>This error is triggered from some kind of monitoring process at
>service-now. It's really annoying and we've filed several bugs on it,
>but haven't seen a resolution yet.
If you figure out which value they're putting into the message, it might
be possible to fool it and create a SAML AffiliationDescriptor in metadata
that authorizes that qualifier. They're not a truly federated service or
in InCommon (broken like Google), so you're in control of the metadata
anyway.
-- Scott
James Bardin
>> We are receiving a 'Invalid SPNameQualifier for this request' status
>> value in our IdP process logs - any guidance on what could have
>> triggered this?
>
> This error is triggered from some kind of monitoring process at
> service-now. It's really annoying and we've filed several bugs on it,
> but haven't seen a resolution yet.
>
On the ServiceNow side, you can just comment out
// nid.setSPNameQualifier(serviceURL);
// nameIdPolicy.setSPNameQualifier(serviceURLStr);
I don't know why they send it, but it's incorrect to specify an
SPNameQualifier with the same ID as the requester. I've asked them to
remove it too, with no response.
-jim
Cantor, Scott
>
>On the ServiceNow side, you can just comment out
> // nid.setSPNameQualifier(serviceURL);
> // nameIdPolicy.setSPNameQualifier(serviceURLStr);
>
>
>I don't know why they send it, but it's incorrect to specify an
>SPNameQualifier with the same ID as the requester. I've asked them to
>remove it too, with no response.
If it's actually the same, and it's not working, that would be a bug in
the IdP. Seems like I saw that and fixed it a while back, it rings a bell
anyway.
-- Scott
James Bardin
>>
>>I don't know why they send it, but it's incorrect to specify an
>>SPNameQualifier with the same ID as the requester. I've asked them to
>>remove it too, with no response.
>
> If it's actually the same, and it's not working, that would be a bug in
> the IdP. Seems like I saw that and fixed it a while back, it rings a bell
> anyway.
>
Ah yes, it was a bug fix for 2.3. I don't think I've tested their SP
against the newer IdP, but I may be able to confirm next week on a new
instance.
https://bugs.internet2.edu/jira/browse/SIDP-464
James Bardin
> On Fri, Sep 9, 2011 at 4:48 PM, Cantor, Scott <cant...@osu.edu> wrote:
>
>>>
>>>I don't know why they send it, but it's incorrect to specify an
>>>SPNameQualifier with the same ID as the requester. I've asked them to
>>>remove it too, with no response.
>>
>> If it's actually the same, and it's not working, that would be a bug in
>> the IdP. Seems like I saw that and fixed it a while back, it rings a bell
>> anyway.
>>
>
> Ah yes, it was a bug fix for 2.3. I don't think I've tested their SP
> against the newer IdP, but I may be able to confirm next week on a new
> instance.
>
> https://bugs.internet2.edu/jira/browse/SIDP-464
>
Turns out there's two different bugs, causing this result.
The shib IdP bug mentioned above, which is fixed, and one service-now bug.
They're generating the SPNameQualifier from their ACS, which may match
in some configurations, so not everyone has this issue. I'll let them
know what the problem is, but Scott's advice of adding a SAML
AffiliationDescriptor in the metadata that matches the SPNameQualifier
would also work.
--
James Bardin <jba...@bu.edu>
Systems Engineer
Boston University IS&T