MSO and multiple communities

[Guy Rixon]

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