on 12/5/2000 7:44 AM, "Tracy Adewunmi" <[EMAIL PROTECTED]> wrote:
> This doc:
> http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-01.txt
> defines a policy server as a "marketing term" to be replaced by the term
> "policy decision point" (PDP) where a PDP is an entity that makes policy
> decisions for itself or for other elments that request policy decisions to
> be made.
>
> My definition of a policy server combines several elements that are
> referenced in the above document and is as follows:
>
> 1. an entity that allows security policies to be defined
> 2. an entity that allows security policies to be retrieved
> 3. an entity that allows groups/roles/permissions to be defined
> 4. an entity that enforces defined security policies
> 5. an entity that interprets security policies inter-domain and inter-realm
> (where domain is defined as a set of hosts with using the same security
> policy and
> realm is defined as a set of resources grouped together under the same
> security policy)
>
> This definition may not be all inclusive but it is how I understand what a
> policy server does. I have looked at the security services API and I just
> wanted to verify that what is there is *not* intended to be an interface for
> the above. However, if I have misinterpreted the power of this service,
> please let me know. I also wanted clarification before I embarked on an
> unneeded journey.
Actually, the Turbine Security system does all 5 of those steps and *is*
intended to be an implementation of exactly what you are talking about.
However, the 5th point isn't entirely implemented within Turbine yet, but it
will be at some point. For now, you can emulate it with properly named
permissions. ie: domain == permission
I'm not sure how that isn't clear looking at the source code.
-jon
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
