Shibboleth Developers

["Alistair Young" <>]

Thanks for your helpful comments Tom. I see more clearly how the domain
cookie works now.
There was mention of having to delete the cookie if the user wanted to
authenticate at a new IdP. We have many users who would want to do just
this, users who are studying at more than one institution and may have
different SP access privileges according to their current institution.
For a lot of users, deleting a cookie may be beyond them :)
It would be nice if the user could bring their IdP domain with them when
starting a SAML session with an SP.
You've probably heard a bit about the Guanxi domain suffix attempt to make
the process of IdP discovery a bit more friendly for the user.
This is in no way to say that the domain cookie/WAYF methods are
"unfriendly" but in a large federation the WAYF lists could get very
large.
I sometimes get mixed up between SAML and Shibboleth, as the SAML profiles
are all post-authentication (I think!) and the Shibb ones are SP first,
with authentication coming second, after IdP discovery.
The domain cookie is then ideal in such post-authentication scenarios.
We're still investigating the consequences of allowing a user to divulge
their 

 to an SP and initially only in the context of the
Bodington VLE and allowing that VLE to then talk directly to a Guanxi IdP
to have them authenticated. Their password is only ever entered at their
IdP.
It all relies on trust, which is what the federations are founded upon.
Can trust be counted on, to allow a user to divulge their ID to a trusted SP?
many irons in the fire at the moment but your comments are much appreciated.
thanks again,
Alistair



-- 
Alistair Young
Senior Software Engineer
UHI@Sabhal
 Mòr Ostaig
Isle of Skye
Scotland

> 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
>> >
>> >
>>
>>
>