SAManage with Shibboleth 3?

[Mark Cairney]

On 20/04/18 14:23, Tom Scavo wrote:
> 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.
Ahh... that's a bit clearer. It's been a while since I "fixed" that 
issue. What happened when they gave it the "nice" FQDN was that the 
response came back from that URL and the IdP quite rightly barfed as it 
wasn't listed as the ACS URL for that SP in it's metadata. I worked 
around this by manually adding it to my local copy of their metadata.

>
>>> 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.
Maybe but from a purely philosophical point of view they (the vendor) 
supply metadata to you (the IdP) in order to integrate with your SP. If 
you have to modify this in any way this means that you're acknowledging 
that their setup is broken!

>> 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.
Right, the paragraph above describes my understanding of the situation. 
If I'd known about the "
WantAssertionsSigned" attribute at the time I could have used that!
>
> If an IdP does not behave as I described above, it is broken or misconfigured.
Thankfully having confirmed that it reverted to default behaviour when I 
removed the exceptions in the relying-party config I'm reassured that my 
IdP *is* functioning correctly although if it wasn't I'd expect a lot 
more to break.
>
> Tom


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.