Re: [xacml-dev] [basic question] PEP recognizing authorized user.

[Yuri Demchenko <demch@chello.nl>]

Bill Parducci wrote:
> Uday Subbarayan wrote:
> 
>> Bill,
>>     Let me make it little bit clear.
>> [1] PEP maintains a session for 30 mins
>> [2] Let's say, a user (User-A) performs an action (Action-A) on a 
>> resource (WS-A).
>> [3] PEP intercepts this request and makes a XACML request to PDP. 
>> Let's say the the response back from PDP is 'permit'.
>> [4]After 10mins, User-A again perfoms Action-A on WS-A.
>> Here, I understood from your response that whether PEP again should 
>> make a request to PDP or cache the previous result is implementation 
>> based, right ?
>  
> yes. the problem is that a PDP can only generate a deterministic answer 
> if given ALL inputs. PEP state information has many variables that are 
> not currently considered. for example, in your explanation what is a 
> 'session'? duration of IP connection? lifetime of authentication 
> assertion on subject? arbitrary time values? in other words, the PEP has 
> many local environment variables that must be considered when you start 
> down this path.
> 
> now you can say that your PEP has a very clear idea of state and that is 
> fine. there is nothing that prevents you from optimizing your 
> implementation. the XACML specification is more limited. this means that 
> you can ask if 'X can access Y for 5 minutes,' but not make any 
> assumptions (via the specification) about X being able to access Y 
> multiple times with a single request. it not that an implementation 
> cannot do this, but that the specification does not account for it.
> 
> does that make sense?
> 
We are doing policy based access control in highly distributed 
environment for collaborative applications and Grids. We need to 
combine few policies and few PDP's. We also identified discussed here 
problems since our first use of XACML.

Our current solution is based on using AuthZ tickets and tokens for 
maintaining access/AuthZ session.

We are currently using two formats for tickets - proprietary and SAML 
1.1/2.0. This is also to mention that SAML turned up to be a bit 
clumsy/verbose for suggested format of AuthZ ticket.

Working with AuthZ/Session tickets required some extensions to current 
RBAC/XACML functionality to provide caching and initial evaluation of 
the ticket/session which we do with the Triage module/function.

Some information about our solution can be found here:

Job-centric Security model for Open Collaborative Environment. - 
Accepted paper for the CTS2005 Symposium, Special Session on Security 
and Collaboration - 
http://www.uazone.org/demch/papers/C-305_cts2005security-oce-jobcentric.pdf

Using XML based security tickets and tokens or SAML demystified - 
http://www.uazone.org/demch/presentations/tf-emc2-authz-ticktok-2005.pdf

The GAAAPI (Generic AAA PI) will be available mid summer. Our plans to 
integrate GAAAPI with EGEE gLite and GT4 AuthZ frameworks for WS based 
Grid applications.

If there is some specific interest, we can discuss directly.

REgards,

Yuri