Skip to Content.
Sympa Menu

mace-opensaml-users - RE: SAMLAuthorizationDecision

Subject: OpenSAML user discussion

List archive

RE: SAMLAuthorizationDecision


Chronological Thread 
  • From: "Ed Reed" <>
  • To: <>
  • Cc: <>, <>, <>
  • Subject: RE: SAMLAuthorizationDecision
  • Date: Mon, 24 May 2004 10:10:10 -0600

Thanks -

So it's clear what I'm interested in -

I'd like to use a SAML-based protocol to utter the following abstract
requests
and get the associated responses:

1) create session: take notice that THIS user with THIS identity
assertion
has authenticated to me
(either directly or via presentation of a SAML assertion from an
identity provider
I trust), and so please inform ME as to the set of roles AVAILABLE to
THIS user
at this time (such a response would take into account whatever temporal
or
other state-driven constraints appropriate) for use on the newly
created
SESSION.

1 response) signed list of roles AVAILABLE to THIS user according to
whatever
policy constratins are known to the SAML assertion provider. Return a
SESSION
handle (think of it as an artifact, if you like) to use as future state
change
requests.

2) activate role: for THIS user on this SESSION, ACTIVATE one or more
roles
from the set of AVAILABLE roles provided in the #1 response, above.

2 response) considering constraints like dynamic separation of duty,
temporal,
as well as session-specific state like connection quality of protection
and
authentication strength of function (provided at session creation time
in #1
above), return a signed set of ACTIVE ROLES for THIS identity in
association
with this SESSION. Optionally, return revised set of AVAILABLE roles
that
take notice that the user is already active in some roles that may
exclude
activation of conflicting roles.

3) deactivate role: same as 2, but remove the one or more roles being
deactivated from the active set, and restore no-longer-conflicting
roles
to the AVAILABLE roles set.

3 response) signed list of ACTIVE roles, and optionally signed set of
AVAILABLE roles

4) destroy session: logout. deactivate all roles

4 response) ack.

Or something similar.

Ed

>>> "RL 'Bob' Morgan"
>>> <>
>>> 5/24/2004 11:54:38 AM
>>>

> Does that mean that you expect a non-SAML protocol that is built
around
> a XACML protocol to be used to ask things like "what roles are
active",
> or "does this user, given whatever roles they're in, have this
> permission at this time"?

I have heard that XACML 1.1 includes support for the evaluation of
"what
can this user do" (could be considered to be "what roles") along with
XACML's traditional support for "can this user do X".

> Is there any protocol work in XACML at all?

Well, the nice thing about XML is you just plop a document into a
transport and you've got a protocol, eh? (he said derisively.) But
yes,
as Scott said, XACML authz reqs/resps would be carried in SAML
protocol,
according to the what the XACML TC told the SSTC.

Regarding whether this is SAML or XACML, the simple fact was that no
one
interested in use of the SAML authz-decision components ever showed up
in
SSTC committee meetings or on the mailing lists as we were working on
2.0,
despite many requests (meta-requests, I guess). So it was hard for
the
SSTC to make any progress on that stuff, without a constituency. But
folks in XACML wanted to work on that, in the XACML context, so the
SSTC
felt that the nebulous community of SAML authz-decision users would be
well-enough served by that work.

I believe it is the case that the OGSA-Authz WG has produced some work
that profiles and/or extends the SAML 1.x authz-decision stuff. I have
no
idea whether that stuff will work with SAML 2.0 or whatever the XACML
TC
is doing.

> I rather thought XACML could be used to express information in
> SAML, and that SAML attribute assertions would likely continue
> to be useful.

When dealing with modern specs that have myriad dependencies and
profiles
and often rather mysterious areas of usage, it's important to be as
precise as possible. So indeed, SAML attribute assertions continue to
be
useful and actively worked on in the SSTC. Some of the SAML 2.0 work
adds
some needed structure to their use. It's the authz-decision stuff
that
has been frozen.

- RL "Bob"




Archive powered by MHonArc 2.6.16.

Top of Page