Re: [higgins-dev] Notes from Feb 27th "Access Control in Higgins" call

[Anthony Nadalin <drsecure@xxxxxxxxxx>]

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