MSO and multiple communities
Reagan Moore
moore at sdsc.edu
Tue Jul 6 18:32:33 PDT 2004
The need for authentication is for access to controlled resources
whose usage is allocated. The approach we take with data grids is:
- public read access to collections
- writes restricted to individuals who own the collection, or have
been assigned write permission by the owner.
- addition of metadata restricted to the curator of the collection
The authentication is done to the data grid. The data grid then
authenticates itself to the remote resource on which the data is
located. The only account needed at the remote resources is the ID
under which the data grid runs.
This approach provides a single sign on environment for access to
data stored within a particular collection that is distributed across
multiple sites. Since we use GSI authentication, the system
interoperates with grid environments.
For the case of access to compute resources, we rely upon GSI. Use
of a compute resource is only possible if the individual has been
assigned an account. The Particle Physics Data Grid and high energy
physics community have established compute grids that span Europe,
the UK, the US, and Japan. The IVOA can choose to do the same. The
approach required establishing the set of certificate authorities
whose certificates would be honored within the compute grid.
Both data grids and compute grids are running today that enable single sign-on.
Reagan Moore
>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
>> > > >
>> >
More information about the grid
mailing list