<samlp:Response> or <saml2p:Response> in the SAML response

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

<samlp:Response> or <saml2p:Response> in the SAML response

JohnWang
Our Shibboleth IDP uses <saml2p:Response> in the SAML response. But, the SAML SP of our partner expects <samlp:Response> in the SAML response. Here are my questions.
1. Is it possible to configure Shibboleth IDP to reply to a specific EntityID with  <samlp:Response> in the SAML response instead of <saml2p:Response>?
2. If an answer of the question 1 is yes, how to do it?
3. If an answer of the question 1 is no, is it possible to configure SAML SP to accept <saml2p:Response> in the SAML response?
4. If an answer of the question 3 is no, is there other way to go around the problem?

Thanks,

John W.
Reply | Threaded
Open this post in threaded view
|

Re: <samlp:Response> or <saml2p:Response> in the SAML response

Peter Schober
* JohnWang <[hidden email]> [2017-05-02 18:53]:
> Our Shibboleth IDP uses <saml2p:Response> in the SAML response. But,
> the SAML SP of our partner expects <samlp:Response> in the SAML
> response. Here are my questions.

Then they have a bug, most likely.

The XML namespace prefixes used are arbitrary, they depend on the rest
of the protocol message for assignment. E.g.:
<foo:Response xmlns:foo="whatever-the-right-URI-is">
should be just as well.

> 1. Is it possible to configure Shibboleth IDP to reply to a specific
> EntityID with  <samlp:Response> in the SAML response instead of
> <saml2p:Response>?

I don't think it's possible at all.

> 3. If an answer of the question 1 is no, is it possible to configure SAML SP
> to accept <saml2p:Response> in the SAML response?

A non-broken SP wouldn't need configiuration for that, it would just
need to know what XML namespaces are and now to deal with them. (Not
specific to SAML.)

> 4. If an answer of the question 3 is no, is there other way to go around the
> problem?

I doubt it. Who is the SP?

-peter
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: <samlp:Response> or <saml2p:Response> in the SAML response

JohnWang
Hi Peter,
Thank you for your explanation. Below is the information of the SP

Entity ID: rpm.newrelic.com
NameID Format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
Consumer Binding urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST

Thanks,

John Wang
Reply | Threaded
Open this post in threaded view
|

Re: <samlp:Response> or <saml2p:Response> in the SAML response

John Dennis
In reply to this post by JohnWang
On 05/02/2017 12:52 PM, JohnWang wrote:

> Our Shibboleth IDP uses <saml2p:Response> in the SAML response. But, the SAML
> SP of our partner expects <samlp:Response> in the SAML response. Here are my
> questions.
> 1. Is it possible to configure Shibboleth IDP to reply to a specific
> EntityID with  <samlp:Response> in the SAML response instead of
> <saml2p:Response>?
> 2. If an answer of the question 1 is yes, how to do it?
> 3. If an answer of the question 1 is no, is it possible to configure SAML SP
> to accept <saml2p:Response> in the SAML response?
> 4. If an answer of the question 3 is no, is there other way to go around the
> problem?

The issue of <saml2p:Response> vs. <samlp:Response> is one of XML
namespaces. The prefix on an XML tag (entity), in other words the part
that begins with some name and ends in a colon (e.g. saml2p: or samlp:)
is an XML namespace qualifier. It says find the name following the
namespace prefix in that namespace. Namespaces *must* be defined in the
XML entity enclosing the use of that namespace. For example:

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"

The xmlns is a namespace declaration. So either the namespace isn't
being properly defined or whoever is parsing the XML isn't processing
the namespace declaration and just assumes it's going to be something
without properly parsing the XML.

This issue is solely an XML issue. It does not have anything to do
directly with SAML.


--
John
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: <samlp:Response> or <saml2p:Response> in the SAML response

JohnWang
Hi John,
Do you have a solution about the XML issue? Should the IDP be modified or SAML SP be modified?  Thanks!

Best regards,

John Wang
Reply | Threaded
Open this post in threaded view
|

Re: <samlp:Response> or <saml2p:Response> in the SAML response

John Dennis
On 05/02/2017 04:14 PM, JohnWang wrote:
> Hi John,
> Do you have a solution about the XML issue? Should the IDP be modified or
> SAML SP be modified?  Thanks!

I don't know, you didn't post enough information. But it should be easy
for you to figure out. Look for the name space declaration. Is it there?
If yet then the sender is OK and the receiver is at fault. If it's not
there then it's the senders fault.


--
John
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: <samlp:Response> or <saml2p:Response> in the SAML response

Brent Putman
In reply to this post by JohnWang



On 5/2/17 4:14 PM, JohnWang wrote:
Hi John,
Do you have a solution about the XML issue? Should the IDP be modified or
SAML SP be modified?  Thanks!


The Shibboleth IdP can not be modified wrt this issue.

The SP has a bug, if it is expecting a specific XML namespace prefix. As Peter said, what's important in namespace-qualified XML is not the prefix (which could be "foo", etc), it's the namespace URI itself.  So yes, the SP needs to be modified.  But probably not in a configuration sense.  Rather their implementation is broken and they need to fix it at the source code level.

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: <samlp:Response> or <saml2p:Response> in the SAML response

Brent Putman
In reply to this post by John Dennis



On 5/2/17 4:56 PM, John Dennis wrote:
Look for the name space declaration. Is it there? If yet then the sender is OK and the receiver is at fault. If it's not there then it's the senders fault.

I can state with 99.999% certainty that the Shib IdP would not send that namespace prefix without the corresponding namespace declaration.  This code has essentially been in use for over a decade.  If there were such an egregious bug, we would have found it long ago.

The receiver (SP) is at fault here.  (And sadly, this is not unusual.  We have seen lots of fundamentally broken XML processing over the years - like trying to do it with a regex or similar).


--
To unsubscribe from this list send an email to [hidden email]