Re: [ggf-ogsa-sec-wg] Two documents

[Sassa <o.otenko@pgt.salford.ac.uk>]

David Chadwick wrote:

> Von Welch wrote:
> >
> > Olle,
> >
> >  This gets at one of the fundamental tensions we had when drafting
> > this - how much information to include in the request?
> >
> >  One could easily imagine a very fine-grained PDP that could use the
> > whole certifiate chain and parameters of the request to render
> > decisions.
> >
> >  And then one can also imagine a world with mostly coarser grained
> > PDPs that really don't want that much detail, and considering that we
> > could be talking large volumes of information in the parameters (and
> > maybe even the cert chain) shipping all this information all the time
> > could be horribly inefficient.
>
> Firstly we have to assume some intelligence in the PEP (AEF in ISO
> 10181-3 terms). It will know for example whether it is operating in push
> or pull mode.

Consider also the following.

When a user sends a request to the Target, he Pushes the action name, action parameters,
and what else. Thus the AEF (PEP) and ADF (PDP) know that they are operating in Push
mode for these attributes (but probably in Pull mode for user credentials).

The idea is that the AEF and ADF could operate in Pull mode, in which case they would
send requests to an Attribute Repository (represented by or working on behalf) of a
user. If such repository does not contain the attributes necessary for decision-making,
then access can be denied with the "lack of information" reason. It becomes the user's
responsibility to provide the necessary attributes on demand.

So the ADF, knowing what information about the action is needed, can always ask the
client to provide more.


> ...>  And my guess would be that the granularity won't be consistent for
> > any PDP - for some actions it may want lots of information, for others
> > very little.
>
> I think the PEP should be able to know how much it needs to send, but if
> it sends too little, then there can be an error diagnostic meaning "more
> info required"

I believe introducing the Pull mode for any attributes required by the ADF (PDP) is a
good idea.

Sending back "more info required" is, in fact, an implementation of such mode, isn't it?
Whether the (lightweight) client supports (server) Pull mode or not, is less important;
what is important, is that if it fails to provide the necessary information, access is
denied.


At the low level the ADF (PDP) can always be in Pull mode. The binding to the actual
repositories could be established by the AEF (PEP) at initialisation time. When the
client cannot operate in Pull mode, the AEF should provide a proxy-object with a
Repository interface, so the (generic) ADF would have to implement Pull mode only. The
proxy-objects would extract the necessary attributes from the request pushed by
non-pulling clients, or communicate to the client, or any repository (e.g. LDAP); the
choice could be implementation-specific.



To summarise,
the problem of delivering the attributes to the AEF is separate from the problem how the
attributes are delivered to the ADF. The ADF<->AEF interaction (via the authorisation
API) can always be in Pull mode. The interaction between the AEF and client requires a
special protocol that allows the AEF to request more attributes from the client. If the
client fails to provide the necessary attributes, access is denied.


Regards,

Sassa
Research Assistant
University of Salford


> ...--
> *****************************************************************
>
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> IS Institute, University of Salford, Salford M5 4WT
> Tel: +44 161 295 5351  Fax +44 01484 532930
> Mobile: +44 77 96 44 7184
> Email: D.W.Chadwick@salford.ac.uk
> Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> Research Projects: http://sec.isi.salford.ac.uk
> Seminars: http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
>
> *****************************************************************