Shibboleth Developers

["Alistair Young" <>]

Thanks Tom, again extremely helpful info.

you raised the privacy issue:

>> The privacy issue must be considered here.  The whole point of
>> federated identity solutions such as Shib and SAML is that the user
>> need not identify him/herself at the SP.  By requiring an e-mail
>> address, you've just blown the privacy issue wide open again.

For static web pages, for example, Shibb/SAML is fine and the SP need not
know the identity of the user. However, as we're implementing shib/saml in
a VLE (bodington), we have to, at some point, deal with the issue of
assessment. A tutor arranges access for their students at another
institution's VLE. As part of such a distributed course, the tutor must be
sure that the students have followed the prescribed course of content and
where applicable, interacted with other students on a bulletin board, all
at the remote VLE.

Shib/SAML will get them into the VLE, with some Guanxi extensions to
create a local user account for each one. However, for the tutor to assess
their progress, the VLE must be able to track them in some way.

It could track them using an anonymous ID that could be resolved by their
IdP to a real ID, or it could use their real ID from the start.

The domain suffix is an attempt to kill two birds with one stone - to
facilitate IdP discovery and allow Guanxi to create a trackable, local
user account in the VLE, for assessment purposes in eLearning.

For normal, static or non-assessed content, we don't see a need to use the
domain suffix. Rather, just use normal shibb/saml. It's just in the
context of eLearning that we need a way to allow tutors in the domain of
an IdP, to be able to gather assessment info on students at another domain
SP.

How they get that info is not a shib or saml problem but the initial
environment for creating an ID to gather such data is greatly influenced
by the shib/saml community and their opinions on trust within eLearning.

In a lot of cases, the user's ID is an impersonal, numeric identifier. I
could see privacy being catered for by having the IdP authenticate the
real ID but then issue an opaque, permanent, IdP resolvable ID to the SP,
which it can use to create a local user account in the VLE. The real ID
being discarded by the SP after authentication at the IdP.

I hope I'm not being too verbose but we have a lot to think about and
we're keen to seek the views on our proposals from the SAML community.

have a good weekend Tom - what's left of it :)

cheers,
Alistair





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

> On Sun, 31 Oct 2004 00:28:33 +0100 (BST), Alistair Young
> <>
>  wrote:
>> There was mention of having to delete the cookie if the user wanted to
>> authenticate at a new IdP. We h>>ave 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 :)
>
> Not only that, but deleting the common domain cookie also deletes the
> user's authn history.  Remember, the value of the common domain cookie
> is a *list* of all IdPs that the user has authenticated against (most
> recent IdP last).  Deleting the cookie is like throwing out the baby
> with the bath water (so to speak :).
>
>> 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.
>
> Yes, that's a good idea, but now the user is responsible for sending
> along another piece of data to the SP.  What if the user does not send
> the data that the SP requires?  What method of IdP discovery does the
> SP fall back on (if any)?
>
>> 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.
>
> Yes, but I could imagine how a WAYF might use a cookie to initialize
> that (long) list with the user's previously used IdP.  The common
> domain cookie takes that one step further and eliminates the
> interactive part altogether, but in the process the user loses the
> capability to choose a new IdP somewhere down the road.
>
>> 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.
>
> SAML1 starts at the IdP but SAML2 is SP-first.  Therein lies the
> introduction problem.
>
>> The domain cookie is then ideal in such post-authentication scenarios.
>
> No, the common domain cookie attempts to solve IdP discovery in SAML2.
>  (If you want to read about the details of the common domain idea, go
> to sun.com and search for "common domain cookie".  A detailed
> implementation of the SAML 2.0 Web Browser SSO Profile with Identity
> Provider Discovery is attached.  Hope this helps.)
>
>> 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?
>
> The privacy issue must be considered here.  The whole point of
> federated identity solutions such as Shib and SAML is that the user
> need not identify him/herself at the SP.  By requiring an e-mail
> address, you've just blown the privacy issue wide open again.
>
>> many irons in the fire at the moment but your comments are much
>> appreciated.
>
> I hear ya! :-)
>
>> thanks again,
>>
>> Alistair
>
> Cheers,
> Tom
>
>>
>> > 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
>> >> >
>> >> >
>> >>
>> >>
>> >
>>
>>
>