MSO and multiple communities

[Guy Rixon]

On Wed, 7 Jul 2004, Martin Hill wrote:

> Wil O'Mullane wrote:
>
> > 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
>
> I got the impression that groups allow a coarse-grained approach to
> assigning privileges and avoid having to track huge numbers of
> individuals.  Groups can span communities and so separate assigning
> privilege from trust.  That way we don't need to ask data providers to
> assign vast numbers of individual privileges.  I'm a bit out of touch
> though :-(

Yes, this is the purpose of groups.  However, when controlling access to files
owned by individuals - think of VOSpace - groups don't avoid the need to
authorize at the individual level.


> > 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 that subject; is there any formal security analysis on the VO?  ie,
> what are we 'defending' against amongst the various services?  I get the
> impression that the majority of services do not need any security, but
> the fact that some do requires a way of passing security tokens between
> all services so that 'fully public' services can pass results or make
> calls to 'secure' services.

There is no formal analysis yet, although we might commission one when we have
an agreed scheme to analysis.

Earlier discussions in AstroGrid identified these threats:

 - Improper access to restricted ("proprietary" archive-data).

 - Improper access to users' own files (MySpace et al.).

 - Accidental damage to ephemeral state (e.g. user A trashes B's query).

 - Accidental damage to permanent state (e.g. user A drops service B's DB).

 - Malicious damage to ephemeral or permanent state.

 - Malicious denial of service attacks (e.g. repeated large queries).

 - Accidental denial of service attacks ("slashdotting" by general public
   when an astronomical even is mentioned in the media).

>From this list one could then subdivide into types of attack or accident.

Note that there's a mixed bag of impropriety, damage and inconvenience in the
categories above. We're trying to exclude all of these with one access-control
system because it seems too horrible to build several systems. But, following
Roy's 2-hands/no-hands message, I wonder if this is the easiest approach.

> >
> > 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
> >>>>>
> >>>
> >
>
>
> --
> Martin Hill
> www.mchill.net
> 07901 55 24 66
> 0131 668 8100 (ROE)
>

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