Subject: Re: [xacml-dev] [basic question] PEP recognizing authorized user.
Bill Parducci wrote: > Uday Subbarayan wrote: > >> Bill, >> Let me make it little bit clear. >>  PEP maintains a session for 30 mins >>  Let's say, a user (User-A) performs an action (Action-A) on a >> resource (WS-A). >>  PEP intercepts this request and makes a XACML request to PDP. >> Let's say the the response back from PDP is 'permit'. >> 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