[apologies for cross-posting; but JISC-SHIBBOLETH seems to need warming up with a bit of traffic, and I don't know what the overlap of membership is]

 

I get your point Ian.  I think the important bit is that we have to get our collective head(s) around the whole idea of delegating trust, amongst a large (therefore scaleable) number of organisations, to a federation.  

 

What *won't* be scaleable is if *every* SP takes the view that it must individually be assured of the security ("trustworthiness"?) of *every* IdP in a fed.  I'm experiencing such an attitude first-hand currently in the process of trying to sign up LSE to use the Shib-to-Athens Gateway run by Eduserv.  Their current procedures require that, having made various written undertakings about LSE network security policies and procedures, we grant a 'test login' to Eduserv so that they can assure themselves (how???) that LSE won't allow access to Athens-protected resources to someone who isn't covered by the LSE licenses to use those resources.  I'm sure Eduserv is doing this with the best of intentions and I don't doubt their integrity.  We're using standard LSE network login credentials (or it wouldn't be SSO, would it?) for AuthN to our Shib IdP, which includes access to various internal resources like shared workstations and wireless network on campus, email, etc.  Our problem is that Eduserv would like a 'test account' that "only gives them access to Athens-protected resources";  and LSE doesn't have any directory attributes that distinguish such a user.  Why would we?  We *could* create a special class of LSE user for Eduserv, but that would rather defeat the object of whatever they want to test.  Or we can give them a 'proper' network account, like one of the users they want to impersonate for test purposes, which *should* (according to the LSE security policies which Eduserv have just audited thoroughly) involve the individual nominated by Eduserv presenting themselves at one of the registration desks on the LSE campus, with an appropriate personal photographic identity document (such as a passport), and signing the acceptable use agreement covering use of internal and external (including Athens-protected) resources that we require from staff and students.  Personally I don't mind too much if Eduserv make poor Phil Leahy get a train to London just to do this (but I suspect Phil might!); or if we compromise our own rules by letting him do this by email.  But I don't want to set a precedent for all SPs to expect to do this!  I'm not a lawyer  - but our highly-talented IT Infrastructure Manager *has* just decided to become a barrister instead!

 

Admittedly, the Gateway is arguably now in the position of being a fed of its' own, rather than just a representative of the collection of resources to which it provides access.  We'll need it for a relatively long time as a way of achieving the transition from Athens.  But I'd hope in due course (soon?) that it becomes effectively just another SP within the wider .ac.uk fed that JISC is seeking to establish, alongside the resource hosts that implement their own SPs  - as Elsevier, JSTOR, EBSCO, etc have already done.

 

In this respect, Athens/Eduserv could be more like the SWITCH VHO (http://www.switch.ch/aai/vho.html) that Nicole has just mentioned  - a way for resource hosts to outsource the job of individual user registration.  At present, 'Athens classic' is a way for institutions to outsource the job of being IdPs  - although most Athens-using institutions already have to duplicate this process and operate as IdPs for access to internal resources;  and they don't pay Eduserv directly for doing this significant job.

 

I too can imagine a situation where some SPs need a higher LOA than most IdPs can offer (many won't have the local infrastructure to support AuthN beyond name/password).  I've for a long time been pushing the argument that we will need to develop some protocols for interoperation between multiple fed's (whether these are national or sectoral or both), for supporting situations where an individual has affiliations with several IdPs (but *please* let's stop calling these "multiple identities" and getting all confused with schizophrenia ;->), possibly across different fed's;  and other complexities.

 

But I can also imagine a highly desirable model for a UK fed to support HE and FE activities / institutions, in which IdPs could register their capabilities to provide different LOAs, and be regularly audited in appropriate ways by the body responsible for the fed.

 

John



	-----Original Message----- 

	From: Ian Young [mailto:[log in to unmask]] 

	Sent: Mon 08/08/2005 10:26 

	To: [log in to unmask] 

	Cc: 

	Subject: Re: [JISC-MIDDLEWARE-DEVELOPMENT] Name Game: levels of authentication assurance

	

	



	Paschoud,J wrote:

	

	> I disagree with Mark that different fed's will be needed to support

	> different levels of identity authentication (for which we could

	> probably safely adopt the levels already enshrined in the UKeGov

	> standards  - unless anyone out there in radiotelescopeland has

	> something that needs more-than MI5/6 levels of security...???).

	

	Despite Mark's own partial recanting of his original post :-) I'd just

	like to point out that the level of assurance issue doesn't go away just

	because you can pass a claimed level of assurance from IdP to SP.  It

	just moves around a bit.

	

	For example, I might see a claim of a high level of assurance in a

	subject's identity coming in from an IdP.  Assume that I trust that IdP

	to manage such claims correctly; that still isn't sufficient for me to

	believe the claim: I also need a high level of confidence in the

	identity of the IdP *making* the claim.

	

	In other words, the more extraordinary the claim coming from the IdP,

	the more confidence I need about the IdP's claim of its *own* identity

	(to avoid the federation becoming the weak link in the chain).   That

	confidence has to come from my knowledge of the policies and procedures

	the federation uses to authenticate entities and distribute the

	corresponding metadata.

	

	There is therefore a tradeoff between reducing the degree of hassle

	imposed on members by the federation policies and increasing the

	ultimate level of assurance in any claims passed between members.  If

	you want the high LOA people to be able to make use of a federation, you

	need to build the federation policies accordingly, which will impose

	some additional burdens on everyone joining.

	

	To come back to Mark's original point, it *is* possible to imagine a

	situation in which the high LOA group just need more than everyone else

	is prepared to sign up to, in which case you would indeed end up with

	multiple federations as the only solution.

	

	        -- Ian

	

	P.S. no, I have no suggestions for the name...