[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: authentication and stuff...
Folks,
We had an interesting if IMHO somewhat vague discussion on the
relationship between authentication and SAML at the meeting. We
were chatting in the cab on the way to the airport about this and
might have come up with a way to clarify things. Be interested in
what the rest of you think about this...
In the following "authentication" means the stage where I
type in a password and that gets checked. It doesn't cover the
stage where a password is picked/established.
Assuming that the following SAML-relevant entities are potentially
"involved" when authentication occurs:-
- an application
- a PEP
- a PDP
- some external (to SAML) authentication service
...here's some examples of ways of handling authentication:-
- The application will check ssl client authentication, e.g.
where the application is a web server. The application
tells the PEP the user's name.
- With RADIUS or SecurID authentication the application might
pass the username/pwd to the PEP, and the PEP might then
pass on these to a RADIUS or ACE server (instances of
external authentication services). In this case the PEP
(might) tell the PDP the user's name.
- Using LDAP password authentication, the application might
pass the username/pwd to the PEP, which (due to f/wall
considerations, say), passes both of these to the PDP which
issues an LDAP bind request (the LDAP server is the
external authentication service here). In this case the PDP
tells other parts of the authorization system the user's name.
- As a result of SSO support (i.e. some previous authentication
step) the application passes a SAML token identifying the user to
the PEP, in the case where the token is treated like a capability.
I think that these examples pretty much cover the flows resulting
from the cases that are most important. If the result of an authentication
step (as defined above) is, to make up a term, a SystemNameAssertion,
and the inputs, (e.g. username/password) *where visible to the
SAML protocol*, is a UserNameAssertion (that should really
be "subject", not "user" but it screws up the acronyms), then it would
seem that a SystemNameAssertion can be created by the application,
the PEP or the PDP and a UserNameAssertion only needs to be sent
between a PEP and a PDP. If a PDP creates the SystemNameAssertion then
it might have to pass this back to the PEP.
The logic here is that though the equivalent of a UserNameAssertion
occurs elsewhere, that will be in some non-SAML-standard format
(e.g. via a proprietary PEP API, as RADIUS messages leaving
a PEP or PDP, or as LDAP bind PDUs from a PDP, in the examples
above). We have to allow for these non-SAML-standard interfaces,
but we don't own or otherwise control them.
I think that for the simple username/password cases and for
cases where the application checks (e.g. ssl client auth), this
is all easy enough. One remaining question is whether we
want to include handling of e.g. SecurID re-synch or multiple stage
authentication as in scope or not. My take on this would be that
the onus is on whoever wants to include these, to describe the
authentication scheme requiring the multiple exchanges and for
the TC as a whole to argue the merits and reach consensus as to
whether or not the particular scheme merits inclusion. Personally,
I don't have an opinion on this right now, but am willing to
swing either way if I see detailed justification based on real
world (i.e. deployed) authentication schemes.
Similarly, I think the onus is on those who want to be able to
support the "step-up" scheme to convince others that this is
useful. In this case, I'm more convinced that we should include
it as in scope. The new flow in this case could therefore include
a "step-up needed" message from a PDP to a PEP.
I've tried to capture some of this in a bit of ascii-art below.
(These diagrams differ somewhat from Hal's diagram from the meeting,
but not in any substantive way.)
My current position is that I think we have to support cases 1-3,
am positive towards case 4 and haven't done any ascii-art for the
multiple-exchange cases since I'm not convinced that any need to
be in-scope for now.
General ascii-art framework - SAML actors involved in authentication.
Application
|
|
|
+---+---+ +------+
| PEP +------+ PDP |
+-------+ +------+
1. SystemNameAssertion (SNA) received by PEP from application (due to SSO)
and (possibly) passed to PDP.
Application
|
SNA |
|
V
+-------+ SNA +------+
| PEP +----->| PDP |
+-------+ +------+
2. Username/password sent to PEP by application. PEP calls to external
authentication service (extAS); PEP sends SNA to PDP.
Application
|
U/P |
|
V
+-------+ SNA +------+
| PEP +----->| PDP |
+---+---+ +------+
|
U/P |
V
+-------+
| extAS |
+-------+
3. Username/password send to PEP by application. UserNameAssertion (UNA)
sent to PDP by PEP; PDP sends username/password to extAS; PDP sends
SNA back to PEP (if applicable).
Application
|
U/P |
|
V
+-------+ UNA +------+
| PEP +<---->| PDP |
+---+---+ SNA +------+
|
U/P |
V
+-------+
| extAS |
+-------+
4. Case 3, but with PDP insisting on a "step-up" (SUP). On receipt of SUP, PEP
presumably triggers entry of a new username/password pair and repeats (not
shown).
Application
|
U/P |
|
V
+-------+ UNA +------+
| PEP +<---->| PDP |
+---+---+ SUP +------+
|
U/P |
V
+-------+
| extAS |
+-------+
Stephen.
--
____________________________________________________________
Stephen Farrell
Baltimore Technologies, tel: (direct line) +353 1 881 6716
39 Parkgate Street, fax: +353 1 881 7000
Dublin 8. mailto:stephen.farrell@baltimore.ie
Ireland http://www.baltimore.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC