Shibboleth Developers

[Tom Scavo <>]

On Sat, 30 Oct 2004 23:51:00 +0100 (BST), Alistair Young
<>
 wrote:
> Would it be possible to see the conformance doc? As part of our JISC
> middleware project, Guanxi, we're investigating an IPDP that doesn't
> require centralised resources for a federation. It also addresses the
> concerns raised of multiple IdP for a user and how they change it.

Alistair, would you care to describe your solution?

> It's also unclear how the domain cookie can be updated reliably if there
> are hundreds or thousands of users authenticating and each IdP trying to
> update the cookie at the same time.

This doesn't seem to be a problem.  After the user authenticates, the
client is redirected to the common domain where after the cookie is
updated on the client.  If you're worried about load on the common
domain server, that shouldn't be a problem since authn is an
exceptional event in an SSO system.

> Of course, there's also the issue of users disabling cookies, although
> institutions could insist that cookies be enabled to use the system but
> how ethical is this?

This isn't much of a problem either.  Like JavaScript, you can disable
cookies on the browser, but if you do you sacrifice a lot.  In
practice, cookies are not disabled (and requiring this is not as
grandiose as it sounds).

> We're keen to allow simple SAML models to be used, where, for instance, a
> couple of VLEs can be hooked up via Shibboleth or Guanxi, without the need
> for extra resources such as a central domain server.

A common domain server need not be a separate physical host.  I think
the intention is that it's more of a DNS trick than anything else.

Cheers,
Tom

> > Thanks for reviewing...my comments below.
> >
> >> - Applicable Shibboleth version is not mentioned anywhere in this
> >> document (intentionally, I presume, but it's still a significant
> >> omission)
> >
> > Intentional. There's an unpublished conformance doc, and there are no
> > implementations of Shibboleth that are conformant. This is not about
> > implementation, so why should we mention one?
> >
> >> - In Example 3.1.1.3, remove the URL encoding for clarity
> >
> > Why? Then the example would be wrong...
> >
> >> - In Examples 3.1.2.1, 3.2.1.1, and 3.2.2.1, insert indentation for
> >> clarity.  Also, refrain from using default and/or redundant
> >> namespaces.
> >
> > Will indent. I disagree about the namespaces, and I don't think any of
> > them
> > are redundant, but I'll check. I use default namespaces all the time. They
> > save space.
> >
> >> - Not sure sections 3.3 through 3.7 should be called "profiles"
> >> - Combine sections 3.3 through 3.5
> >
> > I'm reworking 3.3-3.5 back into the earlier sections (I agree), but they
> > are
> > all SAML profiles, IMHO. Except maybe 3.6, which just points at one. 3.7
> > is
> > probably going to be the basis of an actual submitted SAML profile.
> >
> >> - IMHO, section 3.6 should be omitted.  As written, it adds nothing to
> >> the existing SAML2 "profile", which itself is vague at best.
> >
> > I think we, umm, disagree about the vagueness, or at least the necessity
> > for
> > it to be any less vague. "Doesn't solve an unsolvable problem" I would
> > agree
> > with.
> >
> > We have to reference it because this is a SAML 1.1 based set of profiles,
> > and that's a SAML 2.0 profile that wouldn't otherwise apply.
> >
> >> Moreover, there seems to be a lot of overlap between the IdP Discovery
> >> Profile and the WAYF.  Perhaps the two should be combined?
> >
> > I do, section 2.3 already allows for the use of that profile. The WAYF is
> > a
> > non-normative component, it wouldn't be appropriate to require one to
> > utilize the SAML profile. It dovetails with it fine, since it's
> > essentially
> > usable as a shared domain. It effectively just offloads the SP's role of
> > participating in the profile to it.
> >
> > -- Scott
> >
> >
> 
>