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
*****************************************************************