SAManage with Shibboleth 3?

Tom Scavo trscavo at gmail.com
Fri Apr 20 09:23:49 EDT 2018


On Fri, Apr 20, 2018 at 7:25 AM, Mark Cairney <Mark.Cairney at ed.ac.uk> wrote:
>
> On 19/04/18 19:33, Tom Scavo wrote:
>> On Thu, Apr 19, 2018 at 4:46 AM, Mark Cairney <Mark.Cairney at ed.ac.uk> wrote:
>>>
>> Looking at the AuthnRequest you posted earlier, I see that
>>
>> AssertionConsumerServiceURL='https://desk.ei.ed.ac.uk/saml/edin'
>>
>> so the application apparently knows about your CNAME. How did you
>> configure the SP to use this particular AssertionConsumerServiceURL?
>
> I don't have direct access to the SP- I added the URL manually to my
> local copy of the metadata to work around the issue. The metadata pulled
> from the SP itself doesn't contain any reference to desk.ei.ed.ac.uk

Right, I understand that now, but I wasn't asking about the metadata,
I was asking about the AuthnRequest. Let me try again.

Earlier you posted an AuthnRequest that contained the following XML attribute:

AssertionConsumerServiceURL='https://desk.ei.ed.ac.uk/saml/edin'

Where did that AuthnRequest come from? Usually an AuthnRequest is
issued by the SP, hence my ultimate question: How does your SP know to
add that XML attribute to the AuthnRequest?

For the record, the ACS URL in the AuthnRequest must match the ACS URL
in metadata. So there's an apparent mismatch here. I'm trying to get
to the bottom of this.

>> More importantly, what caused the NameID issues you reported earlier
>> and how did you resolve them? The published metadata [1] has a
>> <md:NameIDFormat> element. Did your snapshot have such an element all
>> along or did you add one recently (after Peter's recommendation)?
>> Basically, what did you do to resolve your NameID issues?
>
> The NameID was the easier of the 2 issues. I resolved it by adding the
> entries in saml-nameid.xml. I also created a specific mail attribute in
> attribute resolver for this SP which strictly isn't necessary but it
> makes it explicit that the attribute exists purely to work with that SP.
> (I consider, rightly or wrongly, any nameID wrangling at the IdP end as
> working around broken SP behaviour)

For the record, I think you did it the hard way. The <md:NameIDFormat>
element in metadata drives IdP behavior with respect to the NameID.
All you have to do is add the element to SP metadata.

> The main reason I contacted the list was actually the signing behaviour.
> My guess is that by not explicitly setting it to enabled or disabled
> allows the 2 parties to agree it between themselves.

No, that's not quite right so let me try to clarify since this is
important. The IdP *always* signs the SAML response, full stop.
Without that, security is lacking.

Since the response is signed, the assertion inside the response need
not be signed. In other words, the signature on the response covers
the assertion since the response contains the assertion.

Some (broken) SPs require the assertion to be signed in addition to
the signature on the response. The WantAssertionsSigned XML attribute
in metadata drives this behavior at the IdP. If an SP requires a
redundant signature on the assertion, it simply adjusts its metadata
accordingly.

If an IdP does not behave as I described above, it is broken or misconfigured.

Tom


More information about the users mailing list