[ggf-ogsa-sec-wg] inter-domain requirements

[Brian E Carpenter <brian@hursley.ibm.com>]

I'd hoped to do a bit more work on this before now but
events conspired against that. However, I've added a few
more remarks below to what I said earlier:

> One possible way of staging security reqts, at least viewed from
> an industrial deployment view, is
>  Stage 1: the single-enterprise scenario (what some people call an intragrid)
>  Stage 2: the inter-enterprise scenario (extragrid)
>  Stage 3: the general case (intergrid).
> The issues of trust relationships, PKI, and security assertions
> get progressively harder as you go through these three stages.
> 
> This may seem a bit odd in the research community which probably
> thinks it's in Stage 3 already, but the reality I think is nearer
> Stage 1.5. As somebody pointed out recently, establishing trust
> relationships etc is a major headache in setting up a grid
> and I think we will need to analyse that in terms of technical
> requirements for the stages mentioned above.

Phil Janson and I have been discussing some ideas about the inter-enterprise
scenario. It seems to us that in general you will need to transfer
security assertions between separate domains inside a given VO, and that
if we think just in terms of how to interconnect Kerberos and X.509
domains we won't get the requisite generality. 

The physical organisations taking part in a VO share resources and services, 
and will negotiate a trust model, but we have to assume they have different
user identity systems, different authentication regimes, and separate 
authorization policy domains. 

We think that to link these system/regimes/domains, there is
a requirement for an abstraction that will serve to represent
a set of security assertions in a canonical format. There could
also be a concrete from of that abstraction for use in inter-domain
security exchanges.

We also think (oops, this is as close to a solution as a requirement)
that the representation of this abstraction should be in SAML for two 
reasons:

1. SAML can readily be transmitted using SOAP, and protected using 
WS-Security. 

2. While X509 and Kerberos are popular and powerful security assertion
syntaxes, they predate enough modern thinking on SAs that they lack 
fields to cover some possible semantics (e.g. authentication method and 
context) and are not as easily extensible as SAML.

We have a few more ideas but they are not quite cooked enough yet.

   Brian