incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David L Kaminsky <...@us.ibm.com>
Subject Re: [Fwd: Re: Incubator Proposal: SPL]
Date Thu, 20 Sep 2007 12:44:58 GMT

Hey Alex,

I looked at the access control for Triplesec, and it looks somewhat like
XACML from Oasis:
  http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

Here are my general thoughts on the overlap between SPL and access control
languages:

1. It is possible to express access control policies in SPL (using if-then
syntax), but it's much more natural to express access control policies
using domain-specific syntax.  For example, XACML has a pretty direct
encoding of "Nurses can access medical records" ("nurses" is the role, "can
access" is the access, and "medical records" is the subject), so it's
natural to express such policies in XACML.  The SPL syntax wouldn't be
nearly as clean.

2. It is also possible to express IT management policies (e.g., "backup the
database when data have changed 10%") using some access control languages,
but you really have to misuse some of their concepts (typically
"obligations"), and the expressions would get really hairy.  In practice,
people wouldn't really want to do it.

At the end of the day, the discussion can end up looking a lot like
discussions of programming languages.  IMO, despite the overlap in some
areas, there's a good reason that people still write in all of C, C++,
Java, Perl, FORTRAN, etc. -- people choose the language that best suits a
particular need.

I don't think we'll need quite the same breadth of policy languages, but I
also don't think we'll get down to one.

David



>
>
> -------- Original Message --------
> Subject:    Re: Incubator Proposal: SPL
> Date:    Tue, 18 Sep 2007 16:36:03 -0400
> From:    Alex Karasulu <akarasulu@apache.org>
> Reply-To:    general@incubator.apache.org
> To:    general@incubator.apache.org, fhanik@apache.org
> References:    <NBBBJGEAGJAKLIDBKJOPMEEOAGAD.noel@devtech.com>
> <46EEC902.8010908@apache.org>
>
>
>
> Hi all,
>
> Over at Directory we have an initial attempt at an identity solution in
> place called Triplesec.
> It does the usual AAA with some additional things like mobile keyfobs
> however it's authorization
> policy management features might benefit from this project or there may
be
> some overlap.  Here's
> a link btw for some additional information on tsec:
>
> http://directory.apache.org/triplesec
>
> Specifically the following information refers to the authorization policy
> store and an API to access
> the information therein which can be stored in LDAP or in an LDIF file
> (exported from LDAP).
>
> http://directory.apache.org/triplesec/guardian-api-users-guide.html
>
http://directory.apache.org/triplesec/authorization-using-guardian-api.html
>
http://directory.apache.org/triplesec/administration-tool-users-guide.html
>
> So the big question is there much overlap here?  An initial glance tells
me
> there might not be
> but I may be wrong.  Thoughts?
>
> Alex
>
> On 9/17/07, Filip at Apache <fhanik@apache.org> wrote:
> >
> > Noel J. Bergman wrote:
> > >> We proposed to develop a policy-based management infrastructure that
> > >> automates administrative tasks by executing policies
> > >>
> > >
> > > Sounds good.  I will be curious to see the reaction from the HTTP
Server
> > > folks, but this sort of thing is very much needed in real-world
> > deployments
> > > of app servers.
> > >
> > >
> > >> The initial goals are to develop an SPL evaluation engine and
> > >> bindings to the APIs for [...]
> > >>
> > >
> > > What about Tomcat?
> > >
> > I'd be happy to help out with this piece, should the vote to incubation
> > go through
> >
> > Filip
> > >
> > >> Nominated Mentors
> > >> -    Bill Stoddard(stoddard@apache.org)
> > >>
> > >
> > > Glad to see that Bill will have cycles for this.  :-)
> > >
> > > Would you please take a look at lokahi (
> > http://incubator.apache.org/lokahi)
> > > and comment on any synergies that you see?
> > >
> > >       --- Noel
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message