From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Anthony Nadalin
Sent: Tuesday, March 04, 2008 6:22
PM
To: Higgins (Trust Framework)
Project developer discussions
Cc: 'Higgins (Trust Framework)
Project developer discussions'; higgins-dev-bounces@xxxxxxxxxxx
Subject: Re: [higgins-dev] Notes
from Feb 27th "Access Control in Higgins" call
Paul, I'm still not sure what problem you are trying
to solve.
Today we have the case where a RST request is coming into the IdP/STS (which
is/can be a authorization service) asking for a set of claims. In order to make
the authorization decision to satisfy the request for claims, the authorization
service ( IdP/STS) must ensure that the requestor has presented and proven the
claims required for access (access to IdAS) . Logically, the authorization
service constructs a table of name/value pairs representing the claims required
by the target service (IdAS). The logical requirement table is constructed from
the following sources and may be supplemented by additional service resources:
• The address of the EPR for the target service
• The reference properties from the EPR of the target service
• Parameters of the RST
• External access control policies
Similarly, the claim table is a logical table representing the claims and
information available for the requestor that the authorization service uses as
the basis for its decisions. This logical table is constructed from the
following sources:
• Proven claims that are bound to the RST request (both primary and
supporting)
• Supplemental authorization context information provided in the request
• External authorization policies
So if there is a match you can access.
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Paul
Trevithick" ---02/28/2008 01:37:13 PM---Attendees
|
From:
|
"Paul
Trevithick" <paul@xxxxxxxxxxxxxxxxx>
|
|
To:
|
"'Higgins
\(Trust Framework\) Project developer discussions'" <higgins-dev@xxxxxxxxxxx>
|
|
Date:
|
02/28/2008 01:37 PM
|
|
Subject:
|
[higgins-dev] Notes
from Feb 27th "Access Control in Higgins" call
|
Attendees
=========
Jeff B. - CA
Jim S. - Novell
David K. - IBM
Paul T. - Higgins
Prateek M. - Oracle
Markus S. - Parity
Duane B. - Novell
Phil H. - Oracle
Tom D. - Novell
Mary R. - Higgins
Brian C. - Serena
Agenda
======
1) Use cases
------------
* What sets of use cases are we considering? (e.g.
Phil Hunt's IGF cases,
Parity's "VRM" R-card cases, David KM's
cases, others?)
2) Motivations
--------------
* Motivations of different groups of higgins
developers to get something in
place.
* Perhaps each "interested" group/person
should speak for a couple minutes
on what Higgins capabilities they'd like to see in
this area
3) Scope
--------
* Policy representation only?
* Policy enforcement?
* Policy authoring?
4) Relationship to other efforts
--------------------------------
* Should we create a Higgins profile of XACML?
* IGF?
* XDI link contracts
* others?
5) Design Choices
-----------------
* Should we keep policy "data" separate
from "resource" data in the Context?
In other words should "policy" point to
"resources"? or is it the other way
around?
* How is policy expressed in the data model?
6) Implementation Choices
-------------------------
* PEP built into IdAS?
* PEP Context Provider?
* PEP as a Context Provider responsibility
7) Control over what resources?
-------------------------------
* see: http://wiki.eclipse.org/Access_Control_in_IdAS#Requirements point
#2
8) Timing/Functionality Tradeoffs
---------------------------------
* Do we want to do something simple and quick AND
on a longer, slower track
something more robust?
* Or should we figure out the long term plan and
then see how to implement
an initial phase
9) Process Issues
-----------------
* Volunteer to lead this work area?
* Meeting schedules, etc.
* Next steps
Links
=====
[1] http://wiki.eclipse.org/Access_Control_in_IdAS <--
the page Jim created
[2] http://wiki.eclipse.org/Access_Control_Use_Cases <--
add cases here
[3] http://wiki.eclipse.org/Simple_Access_Control_Proposal <--
conversation
starter
Meeting Notes
=============
1) Use Cases and 2) Motivations
--------------------------------
Paul: I'll go first. Parity has a short term need
for adding the ability for
the I-Card Manager to query through IdAS a Context
Provider to find out for
a given attribute what operations (modify, delete,
create, get/read) are
allowed. This is one of the gating implementation
tasks that remain to get
r-cards really working [though not the only one].
David: Our primary use cases are related to
relationship access control, in
addition to the usual role-based access control.
The ability to allow one
person (friend, employee, etc.) to control what
another person (friend,
employee, etc.) can access about them.
Phil: We see lots of cases where there was lots of
context involved. E.g. a
doctor in the ER room vs. doctor in
<another setting> would have different
access to medical data. Or contexts where a
specific event is occurring.
Tom: In use of the self-issued materials in IdAS,
we require on the back end
user with sufficient rights to look up a
credential. The issues are related
to opening and authorizing contexts as the
user-proxy as opposed to as, say
a "system" user or an
"administrative" user, etc.
Jim: We know we want to be able to front
traditional data stores and access
control is part of that. We need something that
can work with systems that
have native access control but also the ability to
expose systems that don't
have native access control and overlay access
control.
Jeff: We're interested to move Higgins into the
XACML area. IGF of course.
Also some relevance of IGF for users to define
their own access control.
3) Scope
--------
* policy representation (dump XACML)
* permission on an object
* policy authoring
David: Is policy discovery necessary? There may be
security issues. Also,
you put a lot of burden on consuming applications
to be able to use it when
there is a wide range of policies.
Jeff: Should this [access control] be included as
part of the Higgins
project? I'd hate to slow down Higgins. This is
the next layer up the stack,
but maybe it should be in a separate project.
Jim: This seems like a next thing we're doing.
Jeff: True, but if there was a separation each
could evolve more quickly.
David: My opinion is this. At the least we need to
be able to do permissions
query. The rest of it (e.g. policy management and
some of the engine work)
should be transparent to the application.
Paul: Agreed. Does anyone disagree with David's
comment?
<silence>
Phil: As the next step, do we just want to create
a PEP spot in the Higgins
architecture. We could have policy engines that
Higgins could plug into.
Higgins wouldn't have to worry about managing
policy.
<there seemed to be general agreement that just
adding a PEP integration
interface would be another natural next step
beyond what David had proposed>
4) Relationship to other efforts
--------------------------------
Phil: The general thought with XACML is that it
needs to be profiled to deal
with identity information. We chose XACML allowed
the ability to express
context-based rules as has mentioned.
Prateek: The IGF-AAPML story is around generic
requirements for access
control of an identity service. So we distinguish
between the end-user (e.g.
"active subject"), and perhaps a
"target subject." XACML is a standard
policy representation. There's starting to be a
few XACML engines. So
generally the direction of profiling XACML is a
good direction to go. The
AAPML/IGF view is more centered on how to express
the constraints on access
to identity data specifically.
Tom: I think that XACML was probably able to
express what we wanted in terms
of access control. We went to _javascript_ instead
of XACML for the jspolicy
context provider. _javascript_ was easier to set up,
a language that is widely
known, etc. In the first cut where the
administrators have to edit these
policies on their own, _javascript_ seemed like the
way to go.
Paul: Without XACML editors, XACML is pretty
heavy, is that what you're
saying?
Jim: Some of our [Novell] use cases that we had
were beyond access control.
We wanted policy statements that would support
attribute transformations,
joining transformations, etc. This *could* include
access control type
actions, but our use cases were a superset of
strict access control.
Duane: Sun XACML engine is open source and works
fairly well. It was easy to
map IdAS objects as XACML resources. There's also
a new one on Google code.
6) Implementation Choices
-------------------------
Jim: Some of our design choices hinge on how we
represent policy. If we
extend the Higgins data model to include access
control semantics, then it
feels natural to build something into IdAS. If it
is in the data model such
that it doesn't introduce new elements (i.e. just
more nodes or attributes
on attributes; something that IdAS already
provides access to), then we may
not need to change IdAS much. We just need to
implement the enforcement.
We've talked about provide a stackable CP [Context
Provider] in front of a
Context that doesn't know anything about it as an
alternative to making
every CP responsible for implementing access
control.
Jeff: The CP seemed like a logical place for this
innovation.
Markus: Do all CPs have to support it?
Jim: We could provide an "access
control" CP so that it can provide PEP in
front of theirs (that doesn't provide that
support). This would be common
code that we'd provide so that developers use.
Brian: I have a couple of potential uses for
authorization. The first, as
we've been discussing is to control access to the
IdAS data model objects.
The second is a general facility for authorization
for objects that may be
outside of Higgins. If Higgins makes the
investment to build the auth
facilities to control IdAS objects, we've likely
built 95% of something that
could be used outside Higgins as well. E.g.
authorization of who can use a
BPEL orchestration. E.g. this person is allowed
in/out. The usefulness of
such a facility is much wider than just IdAS
objects.
David: If we define something in this area, we
need to allow partial
implementations by context providers.
Jim: Yes, I think this is a big consideration. We
need to allow for partial
support for access control and discovery of what
any given CP can provide
it.
8) Timing/functionality Tradeoffs AND
9) Process issues
-------------------------------------
Paul: I'll go first. I'd like to see a full
featured access control roadmap
that we can implement in phases. I had thought
that we should start with a
simple access control mechanism (as in what I had
proposed last week) to
handle simple cases and then adding a second, more
comprehensive solution,
on a longer timeframe. I was wrong. Parity will
contribute resources to
implementing in the short term some kind of simple
support for access
control (e.g. querying attributes as to whether
they are permitted to be
deleted, modified, etc.).
Paul: I'd like to ask others on this call for
their level of interest,
contribution and potentially leadership.
Jim: I'm very interested in helping and
participating. I don't feel like I
have a lot of expertise in this area. I worked on
stuff in this area in
IETF, etc.
Phil: I'm certainly interested in participating.
To what level has to be
determined. I'm willing to keep working on it with
others.
Jeff: I'm willing to work on it too.
Markus: I've been working for a while for this XDI
Engine on top of IdAS. It
is a simple way to expose an IdAS Context at an
endpoint. This XDI protocol
has a built-in mechanism for access control called
"link contracts". So I'll
be interested to expose a CP with access control
is to map this technology
and map them to link contracts. I can offer is to
keep informing people
about link contracts.
David: I'm interested in helping as well.
Jim: Should we appoint a project mgr lead, then as
we identify specific
item.
Jeff: I need to take this information back to my
company and see what I can
commit to.
<David mentioned that he needed to check with
IBM before committing>
<Tom said he'd like to participate>
<Phil expressed interest in participating, but
wanted to check with Oracle>
<Brian said he was interested in
participating>
<Paul agreed to lead this work area (e.g. with
another call, etc.) for the
time being in the hopes that someone else would
step forward to take his
place>
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
