OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: SW Frameworks and SAML mechanisms


Hi,
Having been following this work on-and-off since it became
an OASIS activity, I have some questions and comments
bothe regarding the general strategy and how to support a
SAML API.

A difference between SAML and let's say ebXML and BizTalk, is
that SAML goes beyond the technical framework by addressing
things that are not strictly security-oriented but rather content and
context-oriented.

To the [technical] security part I would count: digital signatures, 
assertion-ID's, protocol bindings, protocol flows, validity data etc.
However, "Claims" is IMHO "information" that the parties have
agreed on (in spite of being associated with rights, which can be
derived to security).

In S2ML there was an lighter (IMO better), type of mechansim 
in the form of AzData that was a *framework independent*
extension schema.  To build (and use) a SW framework
based on such methods is very straightforward as the
root schema+ security framework is constant and only
payloads differ.  You simply register a code-class
(implementeting a particular payload schema) and this
one rides on the general framework.  By doing that a
receiver can automatically decode any assertion and
based on received payload schema do whatever
is needed:

Init:
        registerS2MLAzData (myfavoritauthorizationscheme.class);
        registerS2MLAzData (someotherscheme.class);

Usage:
        o = receiveS2MLFrameworkObject ();
        if (o.AzData instanceof myfavoritauthorizationscheme) ...
        if (o.AzData instanceof someotherscheme)...

Customized content (99% of all SAML-apps?), is IMO only valid
within "communities", "domains" or "applications" (like
Shibboleth and network  management to name two extremes),
regardless of method used to achieve this functionality.

Due to the fact that the needs of different "communities" evolve with
arbitrary speed and are totally uncorrelated (as the e-business
world itself), as well as documentation issues, makes me less
convinced that SAML should have bothered with "content" at all.
I.e. XACML maybe  the right thing for one community, then they
should use it, but XACML may also be totally off for another community
that for reasons I would not bother about, prefers to develop
their own auth*-vocabulary and schemas.

A SAML-example of what I mean: The term "Advice" is
relevant in certain scenarious but certainly not in others.
In true server-to-server communication there are seldom
any advices to get, just pretty strict rules to follow.

Naturally, interoperability is ZERO between *different*
"communities" but that's "compliant" with the entire e-business.
As XML-schemas allow compatibility to be automatically
verified both on name and content (and by a thing X-OBI are
working with, also dynamically discoverable), at run-time,
makes their use somewhat manageable at least.

To change the SAML route at this stage is admittedly not very
realistic, but maybe some of the authors of the advanced extension
mechansims could elaborate a bit on how universal binary
SAML components and APIs can be created based
on Schema inheritance or substitution groups? 
As this is fairly new stuff in general, I guess it could be
educating as well :-).

Regards
Anders Rundgren
X-OBI



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC