Shibboleth Developers

[Lukas Haemmerle <>]

> > If so, does anything speak against setting the signing attribute to
> > true
> in:
> > <Handler type="MetadataGenerator" Location="/Metadata"
> > signing="true"/> for the distrubtion shibboleth2.xml?
>
> Well, that doesn't distribute shibboleth2.xml, it generates sample
> metadata which is at best a guess.

Sorry, that's of course what I meant :)


> Also, if you have an open endpoint that causes a digital signature,
> it's trivial to bring down your server. Same problem with signing an 
> AuthnRequest.

How about an option that would limit the access to the signed metadata 
to some IP ranges only or only a certain number/minute.

<Handler type="MetadataGenerator" Location="/Metadata" />

<Handler type="MetadataGenerator" Location="/Metadata"
 signing="true" AlloweHosts="127.0.0.1, 130.59.6.143, 129.132.0.0/16"/>

<Handler type="MetadataGenerator" Location="/Metadata"
signing="true" requestLimitPerMinute="3"/>


> Unless you can prove when they signed it, I don't think you have a
> workable model.

Mhh, why is the time so important? I would say that the URL you download 
is important (compared to the URLs contained in the validated metadata) 
but not necessarily the time.


> > Other question: Is the attribute resolver feature already included
> > in RC1? If so, how can it be used? I have only found information
> > concerning odbc store but not for attributes
>
> The resolver plugin provided does SAML queries for compatibility with
> 1.x. Attributes themselves are stored along with the session in the
> same place as everything else is.
>
> If you want support for local resolution of LDAP or database
> attributes, I don't have a plugin for that, only an API that will
> eventually be documented, although there are javadoc-style docs
> already for every public API in the system.

Ah, I was assuming that the local attribute resolution (from an LDAP or 
DB) was one of the new features of the SP. But I guess I misunderstood 
something. Nevermind :)


> Can I ask what value you expect that requirement to bring?  We tried
> to think this through for the UK, and we couldn't see that anything
> bad (other than non-functionality) would happen if someone handed us
> the wrong public key... certainly no security issues that we could
> think of.

Well, in our case SP descriptions are created while being authenticated 
with SWITCHaai. After creation by an SP admin, the SP description has to 
be approved by an Resource Registration Authority admin (RRA) of the 
organization that this SP description is registered for. The RRA then 
has to check the assertion consumer URLs, required attributes etc. and 
the embedded certificate(s).

Now some colleagues argue like this: If you want to embed certificates 
in the metadata, how do you make sure that the (potentially self-signed) 
certificate that is approved by the RRA was really added to the 
description by the legitimate SP admin and not somebody who stole the 
person's account information? So, what this in the end leads to is the 
RRA making sure a.) that the person really is the person who it claims 
to be and b.) to make sure this person's submitted certificate is the 
one that it intended to submit.

We thought b. could be verified by the Resource Registry downloading a 
signed metadata file from the registered SP and validating its 
signature. This would be proof of possession if you could make sure that 
the downloaded metadata was coming from an URL associated with the 
registered SPs endpoints (which can be very easily verified by an RRA).

However, a. is more difficult to check and could invalidate b. if not 
handled properly. So, what we are thinking of is one or more of the 
following options:
- Only allow embedding certificates issued by one of our 
controlled/accepted CAs. Because getting one of these certs involves 
some identity checking procedure this would solve a.
- Only embed self-signed/not accepted certificates on our own according 
to a to be defined procedure (probably there won't be many of these 
cases anyway)
- Make the RRA asking the registering person to give him the fingerprint 
or part of it in order to approve the SP description. If you could 
enforce that the RRA won't see the fingerprint during the approval 
procedure, he would have to ask for it (by phone preferably). However, 
this is rather complicated and not very user-friendly. Again, a 
trade-off between security and ease-of-use...

But all of these options have their disadvantages of course and 
therefore we still haven't decided yet.

Cheers
Lukas

--
SWITCH
Serving Swiss Universities
--------------------------
Lukas Haemmerle, Software Engineer, Security
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 64, fax +41 44 268 15 68
,
 http://www.switch.ch