RE: XACML scope w.r.t. SAML

[George_Robert_Blakley_III@tivoli.com]

All,

I think there need be no overlap whatsoever.

Normal authorization architectures look like this:

There is a Policy Enforcement Point (PEP) and a Policy Decision Point
(PDP).

The PEP collects information about subjects, information about requests,
and information about targets (also called objects),
and passes this information to the PDP.

The PDP collects information about the policy relevant to this decision,
makes the decision, and returns it to the PEP.

The PEP enforces the decision.

SAML defines assertions about names and attributes.  It may also define
assertions about authentication and authorization
decisions.

XACML could define either or both of the following (which SAML does NOT
define):

     target control information (e.g. ACLs etc...)
     access control policy information maintained by the PDP (e.g. the
rules for combining ACL entries etc....)

The workflow would then be:

     PEP uses authentication system to authenticate subject.  This results
in a SAML name assertion, and
          also perhaps a SAML authentication method and result assertion.
     PEP collects subject control attributes (e.g. group memberships,
roles, etc...).  This results in a SAML
          property assertion
     PEP collects information about the request (and perhaps also context
information)
     PEP collects information about the target (this could just be the name
or reference to the target, or it
          could include the control attributes.  If it includes the control
attributes, they are expressed as
          XACML documents)
     PEP asks PDP for a decision
     PDP collects target control attributes (if not provided by the PEP).
This is expressed as a XACML
          document
     PDP collects policy rules (expressed as XACML documents)
     PDP makes a decision
     PDP returns decision to PEP (this could be expressed as a SAML
decision assertion)
     PEP enforces the decision.

--bob

Bob Blakley
Chief Scientist
Enterprise Solutions Unit
Tivoli Systems, Inc. (an IBM Company)


Hal Lockhart <hal.lockhart@entegrity.com> on 03/01/2001 04:14:11 PM

To:   "'Simon Y. Blackwell'" <sblackwell@psoom.com>, "'ernesto damiani'"
      <edamiani@crema.unimi.it>, "'Xacml-Discuss (E-mail)"
      <xacml-discuss@lists.oasis-open.org>, "Security-Services (E-mail)"
      <security-services@lists.oasis-open.org>
cc:
Subject:  RE: XACML scope w.r.t. SAML




It is  important to understand that at the moment, the scope of SAML has
not been  agreed upon. Even the strawman usecase and requirements are at
the moment the  work of a subset of the TC. After our face to face meeting
tomorrow, this  may get clearer.

Hal
-----Original Message-----
From: Simon Y. Blackwell  [mailto:sblackwell@psoom.com]
Sent: Thursday, March 01, 2001 2:34  PM
To: 'ernesto damiani'; 'Xacml-Discuss (E-mail); Security-Services  (E-mail)
Subject: RE: XACML scope w.r.t. SAML



Ernesto  certainly got my point.



There  is some confusion within SAML itself regarding AuthZ and AuthN.
AuthZ is one  area of clear overlap. However, the information contained in
AuthN, i.e.  authentication events and protocols, could be quite relevant
to establishing  policy, e.g. allow access if the protocol was X9.9. One
would hope that the  representation of such data would be similar, even if
the information is  communicated in separate containers.



Perhaps  someone from security-services could  clarify.



Simon Y. Blackwell

CTO

Psoom, Inc.

Voice & Fax:  415-762-9787



-----Original  Message-----
From: ernesto  damiani [mailto:edamiani@crema.unimi.it]
Sent: Thursday, March 01, 2001 10:15  AM
To: Simon Y. Blackwell;  'Xacml-Discuss (E-mail)
Subject: XACML scope w.r.t.  SAML



I believe  some interesting observations can be made starting from this
excerpt of  Simon's last message:



"Allow  <subject> to <verb> <object> only if they

logged in  using an X9.9 Challenge-Response."



[sblackwell] LARGE PORTION OF MESSAGE  DELETED FOR BREVITY



[R-AuthN]  SAML should define a data format for authentication assertions,
including  descriptions of authentication events. This includes time of
authentication  event and authentication protocol.



[R-AuthZ]  SAML should define a data format for authorization attributes.
Authorization  attributes ("authz attributes") are attributes of a
principal that are used to  make authorization decisions, e.g. an
identifier, group or role membership, or  other user profile information.



I believe that the second requisite is  aimed at prescribing how to
represent <subject>, so there is a strong  overlapping here. am I right?

As for the first requirement, honestly I  am not sure I fully understand
it. Are "description of authentication events"  prescriptions about
authentication algorithms, as in the "only if" part of our  initial
example?

If this is the case, this is outside our  scope and could be dealt with in
a separate namespace.

I am inclined to think that separate  namespaces should be defined for the
XML-AC language itself (Allow  <subject> to <verb> <object> ) and for the
prescription of  authentication techniques and the like. But perhaps I got
the second  requirement wrong..



Best regards



Ernesto