[Concordia] AC/LoA summary and call for scenarios
Paul Madsen
paulmadsen at rogers.com
Fri Aug 29 15:00:18 EDT 2008
Hi Eve, thanks for this great summary.
Acknowledging your goad, NTT is seeing a use case develop that appears
to bring to light some discontinuities between SAML AC & OpenID PAPE .
The use case has a SAML IdP providing strong authentication to its
constituency of RPs. The IDP wants to focus exclusively on strong
authentication methods, but the SAML RPs do still have the need for
lower end password authentication in addition to stronger mechs.
Consequently, the SAML IdP wants to outsource such pwd authentication to
OPs (possibly whitelisted) through OpenID. If and when a SAML RP sends
an authentication request to the IDP specifying strong authentication
(either directly or through some stipulated assurance level) using
authentication context, the IDP will deal with the request itself. But,
should the RP ask for a password authentication, the SAML IdP will proxy
that request to an OP, using PAPE to stipulate an appropriate
authentication policy (and subsequently proxy back the resulting OpenID
response.)
We see value for the SAML RPs in being able to leverage their existing
SAML investment & business/trust relationship with the IDP in order to
access OPs. For the OPs, it's a set of RPs that they might not otherwise
be able to serve (albeit indirectly).
SAML RP ------------------> SAML IdP/OpenID RP ----------------------->
OpenID
authncontext
pape
<----------------
<----------------------
So, as we've seen before, a protocol chaining scenario. But,
1) PAPE does not define a URI for 'password' authentication. So, the
SAML IDP (when acting as an OpenID RP) cannot directly proxy on the
authentication policy as expressed in the authncontext of the SAML
authnrequest from the RP
2) While PAPE does support NIST 800 63 LoA (perhaps mitigating #1 above)
SAML's support for NIST 800 63 is currently work in progress in SSTC.
And, even once SAML can carry NIST 800 63 LoA, given the dependence of
the LoA on what NIST calls 'assertions', can we map directly between the
two protocols, ie is openid.pape.nist_auth_level=2 automatically
equivalent to the corresponding SAML authn context class URI?
In other words, do the SAML Web SSO profile and the OpenID protocols
deliver equivalent assurance to RPs in and of themselves, irrespective
of what went on before they kick in (and acknowledging that NIST 4
prohibits both of them.)
3) The preferred 'assurance' mechanism for SAML, whether authncontext or
attribute, is still up in the air.
4) Not directly an issue for our use case (as higher assurance requests
are not proxied to OpenID), but the PAPE spec indicates [1] (non
normatively) how some common authentication mechanisms map into the 3
PAPE URIs. Should this table serve as input to any mapping exercise
Concordia might perform between SAML AC classes and the PAPE URIs?
[1]
http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-01.html#anchor13
Regards
Paul
p.s. wrt 'papist', I'm not sure the OpenID philosophy is compatible with
monotheism
Eve Maler wrote:
> I'm using "AC/LoA" as a shorthand for (SAML-ish) authentication
> context, (NIST-ish) levels of assurance, and similar (e.g., PAPE-ish
> -- papist??) types of contextual information surrounding a federated
> identity interaction. On Tuesday, we agreed that it's worthwhile for
> Concordia to examine the use cases that drive these needs.
>
> Please treat this message as a call for interop scenarios. As we get
> clarity, we can capture everything on the wiki. (Now's a great time
> to get your interested colleagues to join the Concordia alias.)
>
> State of play
>
> A number of Concordia community folks held an ad hoc BOF at an
> unrelated F2F meeting back in May to discuss this general matter, and
> we continued in email. I'll try and summarize those themes here, and
> welcome input/corrections from others.
>
> We know there is existing work going on in a number of venues:
>
> - Liberty Identity Assurance work, focusing on "meatspace"
> certification that an IdP can produce a certain NIST 800-63 level
> https://www.projectliberty.org/liberty/strategic_initiatives/identity_assurance
>
> - SSTC: Eric Tiffany's profiles for encoding NIST LoAs using the SAML2
> authn context mechanism
> http://www.oasis-open.org/committees/download.php/28706/sstc-saml-loa-authncontext-profile-draft-01.pdf
>
> - NIST/SSTC: discussions about refining their overly broad prohibition
> against "assertions"; SSTC HoK profiling may be relevant
> http://lists.oasis-open.org/archives/security-services/200808/msg00006.html
> http://wiki.oasis-open.org/security/SamlHoKWebSSOProfile
> http://wiki.oasis-open.org/security/SAMLHoKSubjectConfirmation
>
> - OpenID PAPE<->SAML2 mappings: we anticipate a proposal from Paul M.
> on this
> (forthcoming)
>
> But lots of questions remain unanswered. For example, there may be
> reasons to use a different mechanism than the one Eric proposes even
> if you use SAML2; it would be useful to have a "decision tree" that
> helps people decide (as well as possibly proposing additional profiles
> as needed). We're also seeing mixtures of technologies that cover
> similar ground, such as PKI vs. SAML metadata and OpenID PAPE vs. SAML
> authn contexts, and stacking of technologies, such as WS-Fed usage of
> SAML assertions. And we're seeing legacy concerns (SAML1.1 is still
> out there) and deployment concerns (different patterns of support for
> optional features) have an effect on interoperability. There seems to
> be useful work for Concordia to do here!
>
> Scenario brainstorming
>
> Here is food for thought about useful scenarios to capture. The basic
> need is the ability for an RP to get assurance from an IdP about the
> "quality of the identity" that is this transaction's subject (which
> may include aspects of original registration of that identity, the
> authentication done this time, levels of security involved overall,
> security during this transaction, etc.). The subtleties beyond this
> have to do with:
>
> - How much specificity is required?
> . LoAs are a "shorthand", vs. authn context specifics -- but is
> there a need to dig into contextual specifics even among LoA users?
>
> - How much dynamicism is required?
> . Out-of-band static agreements about contexts/levels, so that only
> the token carries it all
> . Metadata stating what's possible to do or ask for
> . Totally dynamic requesting of a particular context/level
> . Rejecting the results of an invalid context/level
> . ...
>
> - What are the needs driving different technology choices?
> . PKI vs. SAML for managing context/level abilities
> . Needing to work within SAML1.1 limitations vs. an environment
> that includes usage of SAML2 or others
> . Incorporating SAMLn.n assertions within WS-Fed
> . Mixing SAML (attributes or authn context) and OpenID (PAPE)
> technologies
> . The fact that technology choices have impact on the universe of
> possible levels supported (lower security = lower levels...)
> . ...
>
> Quick review of SAML solutions
>
> Since SAML assertions and protocols are at the heart of a lot of this
> discussion, it seems useful to provide a roundup.
>
> SAML1.1 has no ability to request any particular authentication
> context (or anything else, for that matter :-). You pretty much have
> to use attributes to hold context/level information. Some in
> government and higher ed have standardized ways to do this, though
> we're given to understand that a move to SAML2 and different methods
> are being considered as reasonable options by all parties.
>
> SAML2 has two obvious ways to hold context/level information in an
> assertion: attributes (similar to SAML1.1) and authentication context
> classes and their attendant declarations and reference mechanisms.
> This latter is what Eric has specified in his profile mentioned above.
>
> There are protocol implications to choosing one or the other. With
> attributes, you technically have a way to request the attributes you
> want (e.g., "I need level-2 assurance") through metadata and the
> AttributeConsumingServiceIndex feature of an AuthnRequest. However,
> because the attribute mechanism is generic and the attributes might
> have been retrieved prior to/outside the authentication process, you
> can't safely assume that using the metadata will control the login
> process, even with ForceAuthn.
>
> SAML has a robust metadata structure that could be used in various
> clever ways to help IdPs and SP/RPs manage their expectations around
> context/levels in a more or less dynamic manner, depending on how you
> want to do things; the higher-ed folks take advantage of this.
> However, some, particularly in government, tend to lean more heavily
> on PKI-specific methods, and some go with entirely static out-of-band
> negotiation methods.
>
> A NIST prohibition against using any "assertions" at all for level-4
> assurance recently came to light. The prohibition uses a definition
> of "assertion" that appears to apply to SAML assertions and other
> tokens of all types, including SAML assertions used in the canonical
> types of SSO that are widely supported. However, what NIST likely
> intends is a level-4 prohibition on *bearer* tokens, and there's
> ongoing work (as mentioned above) to more carefully craft the relevant
> wording and define other kinds of SAML assertions that would meet the
> level-4 test.
>
>
> Eve Maler +1 425 947 4522
> Principal Engineer eve.maler @ sun.com
> Business Alliances group Sun Microsystems, Inc.
> _______________________________________________
> Community mailing list
> Community at projectconcordia.org
> http://lists.projectconcordia.org/mailman/listinfo/community
>
>
>
--
Paul Madsen e:paulmadsen @ ntt-at.com
NTT p:613-482-0432
m:613-282-8647
aim:PaulMdsn5
web:connectid.blogspot.com
More information about the Community
mailing list