MSO and multiple communities

[Wil O'Mullane]

> 
> Making every user set up an account with every community which manages
> groups they are joined to (and groups that those groups are joined to? and
> ...) will simply not work.
That was never implied - in the discussiosn we had in boston 
the agreement was that this would prbably be done behind the scenes.
I will have an accoutn for each user on my system but I will create it 
the first time I see their identity

> 
> Cheers,
> Tony. 
> 
> > -----Original Message-----
> > From: owner-grid at eso.org [mailto:owner-grid at eso.org] On 
> > Behalf Of Guy Rixon
> > Sent: 06 July 2004 15:28
> > To: Grid and WebServices
> > Subject: Re: MSO and multiple communities
> > 
> > Let's clear something up.
> > 
> > Hands up all those who think that service providers to the 
> > IVO are required to accept identity warrants from any 
> > community CA inside the IVO.  Hands up those who think that 
> > providers will actually do this.
> > 
> > If we get this kind of universal trust, then we can have true 
> > SSO while still having multiple communities.  If not, then we 
> > automatically some form of MSO and _nothing_ we can do 
> > changes that without breaking the integrity of the system.
> > 
> > I reiterate: if user U is registered at communities C1 and 
> > C2, and if service S trusts C1 and distrusts C2, then C1 
> > _cannot_ rightfully act as a sign-on proxy for groups in C2 
> > when talking to S.  U _must_, somehow, sign on separately to 
> > C1 and C2.
> > 
> > On Tue, 6 Jul 2004, Guy Rixon wrote:
> > 
> > > On Tue, 6 Jul 2004, Dave Morris wrote:
> > >
> > > > Guy Rixon wrote:
> > > >
> > > > >>Would it work if a Community issued a warrant 
> > (certificate) when 
> > > > >>an Account joined a Group at that Community ?
> > > > >>An Account would then have a primary identity 
> > certificate signed 
> > > > >>by their 'home' Community, to prove who they are, plus a set of 
> > > > >>membership certificates signed by other Communities to 
> > prove that 
> > > > >>they belong to Groups on those Communities.
> > > > >
> > > > >Nearly.  The warants are supposed to be short-lived, so 
> > the group 
> > > > >warrants have to be collected at time of sign-on (start of each 
> > > > >session). Therefore, one has to be able to find all the 
> > > > >group-granting communities from the primary community.  
> > That's doable.
> > > > >
> > > > >
> > > > Yep, if a Community for an Account keeps a list of Groups 
> > that that 
> > > > Account is a member of, then it can use this to get the 
> > membership warrants.
> > > > Could even be delayed, and only done when a warrant is required.
> > > > Client service could keep a cache of membership warrants for this 
> > > > session, and only call the remote Communitites when it needs to 
> > > > prove group membership.
> > > > This avoids a message storm of warrant requests when a 
> > user logs in 
> > > > to check the news pages.
> > > >
> > > > However, there is a useability problem with this model.
> > > > a) The user needs to be aware of what membership warrants are 
> > > > required for which actions and selects them when 
> > designing a workflow.
> > >
> > > This would be a policy look-up on the registry.
> > >
> > > > b) All the membership warrants are sent with every 
> > message (message 
> > > > bloat - a 2 line status request may end up with 50+ 
> > warrants in the header).
> > >
> > > A good reason for using X.509 instead of SAML - much more compact.
> > >
> > > > c) The system works it all out - a complex problem that we havn't 
> > > > solved yet (particularly if workflow execution can 
> > dynamically swap 
> > > > between equivalent services based on availability etc.)
> > >
> > >
> > > (d) Back to the pull model: service knows which groups are relevant 
> > > (because service has internal authorization tables mapping 
> > groups to 
> > > privileges) and which communities host which groups 
> > (because it looked 
> > > them up when setting up its authZ tables); so service pulls the 
> > > warrants required from the community services.
> > >
> > > Pro: minimized warrants sent to service.
> > >
> > > Con: service has to interact with many communities at time of call; 
> > > all must be up and there are more (but smaller) messages.
> > >
> > > Con: user agent has to associate the same key pair with all the 
> > > communities => user agent has to log in to each community 
> > at the start 
> > > of the session => use ragent has to know which communities 
> > are relevant.
> > >
> > > > Dave
> > > >
> > > >
> > >
> > > Guy Rixon 				        gtr at ast.cam.ac.uk
> > > Institute of Astronomy   	                Tel: +44-1223-337542
> > > Madingley Road, Cambridge, UK, CB3 0HA		Fax: 
> > +44-1223-337523
> > >
> > 
> > Guy Rixon 				        gtr at ast.cam.ac.uk
> > Institute of Astronomy   	                Tel: +44-1223-337542
> > Madingley Road, Cambridge, UK, CB3 0HA		Fax: 
> > +44-1223-337523
> >