MSO and multiple communities

[Wil O'Mullane]

we do not need accounts or certificates for the simple jobs 
so no not necessarily for all 10k users
but for the perhaps1k who want a more sophisticated service yes

If i really do not need to identify users then why are we doing this at all
we do not need security or certificates 

On Tue, Jul 06, 2004 at 10:20:39PM +0100, Tony Linde wrote:
> > I will have an accoutn for each user on my system but I will 
> > create it the first time I see their identity
> 
> So anyone who ever uses any data or software on your machine will get an
> account created - possibly 10000 plus of them. Why? If all you're going to
> do is create the accounts when you see the identity, why go to the bother?
> Why not just run the job anyway? Or are you going to add them to all the
> groups that your apps and data use to encompass privileges? And how are you
> going to recognise when people are added to and removed from groups? It
> isn't going to work.
> 
> We've sold the IVO on the idea that anyone can get at any data anywhere. If
> you're going to manage that on the basis of every user who ever signs up to
> the IVO having an account on every system attached to the IVO, it simply
> wont work. It is like saying that I have to have an account on every http
> server in the world before I can browse the web.
> 
> All the mechanics has to be transparent to the user and relatively simple to
> implement or it won't scale.
> 
> Cheers,
> Tony. 
> 
> > -----Original Message-----
> > From: owner-grid at eso.org [mailto:owner-grid at eso.org] On 
> > Behalf Of Wil O'Mullane
> > Sent: 06 July 2004 19:20
> > Cc: 'Grid and WebServices'
> > Subject: Re: MSO and multiple communities
> > 
> > > 
> > > 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
> > > > 
> >