Feedback on use of AuthorizationDecisionStatement

["Mishra, Prateek" <pmishra@netegrity.com>]

----------------------------------------------------------------------------
Hi Prateek - 

As part of the distributed grid authorization system for the NASA IPG, we
use AuthZDecisionStatements in their native form, i.e. we have not defined a
custom schema that extends the AuthZDecisionStatement within the grid
authorization process.  We use custom actions within the AuthZD statement to
indicate that the PEP may link the requester temporarily to a local account,
e.g. to run a process.  Together with several attribute statements that
present information about the local groups or roles that should be assigned
to the selected local account, this creates a complete package within an
assertion from a PDP to setup a temporary account mapping for a previously
unknown user that possess the correct authorizations to access local
resources.

This process can begin in one of two ways:
1)  The principal can request access of the PEP which will contact the PDP
directly to request the AuthorizationDecision.

2)  The principal can contact a PDP directly and request access to a
particular resource.  The PDP returns the AuthZDecision assertion to the
principal which can the forward the assertion to the appropriate resource
access manager.

The process may continue as follows:
During the execution of authorized actions at a resource, it may become
necessary to access additional resources, for example a data store or a
specialized instrument or additional processing power etc.  Selecting the
resources that will be used at this point is typically a brokered process in
which the characteristics of the request and the resource are matched.  On
each resource, the subject and authorization information is shared.

Finally, each principal must be able to determine the current status of a
'local session' at a particular resource.  The concept of an assertion (or
request/response) identifier mechanisms provide identifiers by which this
information can be queried from a lightweight AttributeAuthority embedded
within the PEP.   This AA has the ability to report execution-related items
such as 'duration of connection', 'local account name assigned', 'cost of
process', etc.  


The biggest benefits of the SAML AuthZDecisionStatement, for this system,
are:

1)  The stateful protocol framework within which the query/statement
natively fit.
2)  The ability to represent completely in the AuthZDecisionStatement the
details of the request, including subject, resource and action, in addition
to the decision - as the enforcer may not necessarily be the initial
requester.  
3)  The ability to return a set of assertions within the Evidence element
that contain information used while making the decision so that they may be
forwarded on to additional PEPs if new resources must be acquired.

Although pushing this aspect of functionality to another TC such as XACML
may be a longer term solution, my understanding is that XACML TC has closed
the work item list for version 2.0 which would create a gap in supported
functionality.  I would hope that any deprecation of the statement would
occur after an alternative solution has been specified in another standard.


Regards, 
Rebekah
----------------------------------------------------------------------------
Prateek, Rob,

 I'm involved in a couple of efforts right now using the both of the SAML
Authorization elements you mention. I've been meaning to get more involved
with both the SAML and XACML TCs, but cycles have been scarce and I've
preceived the TCs' interest to be low.

 My own perception is that the XACML TC doesn't have any momentum on this
problem right now and is unlikely to address this before SAML 2.0 comes out.
Given this I would preferr not to have the Authz portions of SAML deprecated
until the XACML TC is at least working on addressing this just so we don't
end up in a situation without a "live" authz protocol.

 In regards to what how groups I'm involved with are actually using the SAML
Authz elements:

 The first is the work being done in the GGF OGSA-Authz working group. We're
wanting to defined a protocol/interface between a grid/web service and a
authz service and have been working on extensions that we'd like to see to
better meet Grid needs.

OGSA-Authz WG: https://forge.gridforum.org/projects/ogsa-authz/

 The second is we, the Globus Alliance, have developed an push-based
authorization system using SAML authz elements called the Community
Authorization Service. It is basically what you would expect from a
push-model authz service - clients get AuthorizationDecisionStatements from
the service which they present to a PEP along with their request. The PEP
uses the statements to determine whether or not to allow the servicing of
the requests. More detail can be found in the following document we wrote
up:

http://www.globus.org/Security/cas/Papers/SAML%20Feedback-aug19.pdf

Von Welch

----------------------------------------------------------------------------

To: Prateek Mishra and Rob Philpott
Re: SAML 1.1 AuthZDecisionStatement and AuthZDecisionQuery usage

LearningStation has deployed a SAML service (1.1 and 1.0) that supports
authorization decisions.  I'm not sure what you'd like to know, so I'll
describe how we use AuthZStatements in our service, and you feel free to ask
any questions.

The LearningStation Education Desktop provides about 1 million K-12 students
with seamless access to secure resources from many different security
domains, and our SAML service is now our primary point of integration for
the many third-party vendors who supply content we distribute through our
Education Desktop product.

We support several classes of <saml:Action> values, all proprietary to our
products and systems.  One class defines <saml:Action>'s that identify
whether a user may launch, administer, and/or support resources on our
Education Desktop.  We are planning on another class related to resource
sharing - e.g., allowing a teacher to create a secure resource and issue
"passes" ( taking the form of an Assertion containing an AuthZStatement  )
to other students and teachers to allow access the secure resource.  We even
have a class used internally by our inter-site transfer service
implementation to determine whether a requester has the right to generate
assertions for third-party content.

The AuthZ* schema fits our product and needs well.  We've defined a simple
URI syntax for identification of Education Desktop resources, vendors,
users, and the many different components of our backend system.  The
extensibility of the <saml:Action> element is flexible enough to allow us to
do anything we can fathom.

The only stumbling block we've had in dealing with AuthZ* is deciding how to
approach certain situations that are not nailed down in the SAML spec.  For
instance, if an AuthZQuery contains two actions, one is authorized and the
other isn't, how should the response be crafted?  Should we issue two
statements, one permitting and the other denying?  Or should be consider the
actions together when making the decision ( which would be to deny both
actions )?  Situations like these can lead to problems when our SAML
consumers expect us to behave one way when in practice we behave another, so
we've tried to head off any issues by providing extensive documentation on
our service behavior.

HTH.  As I said, if you have any questions, feel free to contact me.

Obliged,
jim christopher
senior developer / r&d
LearningStation