Discussion of use cases and implementation experience integrating with Workday

[Steven Carmody <>]

Altho its not obvious from this note, I believe Archana works for 
Workday, and is involved in the discussion about step up authN with SAML 
.... she is clearly asking some questions


-------- Forwarded Message --------
Subject:        [saml-dev] RE: SAML + Step up
Date:   Thu, 3 Dec 2015 10:07:44 -0800 (PST)
From:   Hal Lockhart 
<>
To:     Archana 
<>
CC:     SAML Developers 
<>



Thank you for your interest.

I am pleased to answer your questions as well as I can. There is also a
mailing list 
()
 which you can use to ask
technical questions like these. Not only are there people on it with
deep knowledge of the SAML specifications, but also experience in many
different deployments. I have taken the liberty of cc’ing the list so
that others can provide additional information. Like all mailing lists
at OASIS the archives are visible to anyone.

https://lists.oasis-open.org/archives/saml-dev/

You can join the list by agreeing to the OASIS IPR policy. The list is
open to anyone, not just OASIS members.

The short answer to your question is that it is possible in principle to
do these things, however you may find some limitations imposed by other
protocols or software you are required to use, such as a web browser.
The general principle that you should keep in mind is that SAML simply
delivers information to the SP. It is up to the SP to decide what
information to trust, how long to trust it, what information is required
for given purposes and how many different Authentication Statements to
retain.

Answers to your specific questions:

I was wondering if this is even possible with step up:

1.         Allow users to initially login using SAML(username/password)
and obtain a session.

2.         When these users try to access certain actions, allow them to
maintain their current session + provide them with an elevated privilege
session by sending them back to their SAML provider and asking them to
authenticate via 2FA(from the IdP side)?

Yes, this is essentially the step-up usecase.

Questions that I had:

1.         Is it possible to do this without asking the user to re-auth?

Yes. The general SAML mechanism is the Authentication Request
(AuthnRequest). It has two important Boolean options: ForceAuthn and
IsPassive. If ForceAuthn is “true” it means that the IDP must force a
new Authentication interaction, it cannot simply report an
Authentication that took place previously, no matter how recently.
“False” is the default.

If IsPassive is “true” then any Authentication performed must not
involve the user. (If it cannot do this, it must return an error rather
than forcing a user interaction.) Again the default is “false”.

Depending on your requirements, you would want to set IsPassive to
“true” and set ForceAuthn to “true”  or “false” depending on whether a
previous Authentication is satisfactory.

2.         If yes, if the user does not successfully authenticate using
the secondary factor, is it possible to hold the current session valid
so that they can perform regular actions/tasks that don’t require
elevated authentication?

The SP is free to retain any or all of the Assertions it receives from
the IDP and apply whatever policies it chooses to them. However, if you
are using someone else’s SAML client, they may not permit this behavior.
Some implementations discard previous Authentication Statements and in
effect start a new session with each authentication.

3.         Is there any place in the SAML spec that you could point me
to for this?

The AuthnRequest is documented in section 3.4 of the SAML Core:

http://www.oasis-open.org/committees/download.php/56776/sstc-saml-core-errata-2.0-wd-07.pdf

You will also want to look at the Bindings and Profiles specifications
to see what ones apply to your environment.

http://www.oasis-open.org/committees/download.php/56779/sstc-saml-bindings-errata-2.0-wd-06.pdf

http://www.oasis-open.org/committees/download.php/56782/sstc-saml-profiles-errata-2.0-wd-07.pdf

My slide deck also mentions the Identity Assurance Profiles and the SP
Request Initiation Profile as being potentially relevant.

http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-assurance-profile-cd-02.pdf

http://docs.oasis-open.org/security/saml/Post2.0/sstc-request-initiation.pdf

4.         Would it be easy to maintain deeplinks and send the user back
to the right page after they authenticate? How would that work for IdP
initiated SAML?

5.         Would this work for both SP and IdP initiated SAML?

This is exactly what happens in the SSO flows. The HTTP redirect
mechanism allows the SP to involve the IDP to perform the Authentication
and then resume processing the user’s request.

This does not normally work with an IDP initiated flow, because the IDP
does not usually know what the user is asking to do nor what
Authentication type is required for that request.

Other considerations

As mentioned in the slide deck, XACML policies provide a means to
determine that some different Authentication is required from the
current request. If you are implementing access control policy is some
other way, you will have to provide this somehow.

There are many different authentication methods and more are being
invented every day. Deciding which ones are the same strength or  which
ones are stronger than others can have significant commercial and even
political implications. On the other hand, dealing with every method as
an individual case may prove error prone and hard to administer. One
approach some organizations have taken, especially governments is to
define a small number of Levels of Assurance (4 is popular) and
associate every Authentication Method with one of the levels. Thus
instead of requesting the blue banana ear geometry authentication
  method, the SP would request a LOA method.

Another approach to this problem is to use Dynamic Roles. The idea is to
have different Roles, such as User or Admin require different kinds of
Authentication. Depending on requirements, it would be possible to allow
users to deliberately enable or disable a certain Role, in addition to
having it done automatically based on the operation requested. I am
usually a critic of RBAC, but this is an exception.

I hope this gets you started. Other people on the saml-dev list may have
additional comments.

Hal

*From:*Archana 
[mailto:]
*Sent:* Wednesday, December 02, 2015 7:16 AM
*To:* Hal Lockhart
*Subject:* SAML + Step up

Hi Hal,

I came across your presentation on Step up Authentication using
SAML(https://www.oasis-open.org/committees/download.php/52128/Step%20Up%20AuthN%20in%20SAML.pptx). 

I found it very interesting but I had a few questions about this topic
since I couldn’t get hold of the actual recording for the presentation
:) I emailed OASIS and was sent to
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security. I
saw your email address and thought that I’ll email you directly since
you had presented on this topic.

I was wondering if this is even possible with step up:

 1. Allow users to initially login using SAML(username/password) and
    obtain a session.
 2. When these users try to access certain actions, allow them to
    maintain their current session + provide them with an elevated
    privilege session by sending them back to their SAML provider and
    asking them to authenticate via 2FA(from the IdP side)?

Questions that I had:

 1. Is it possible to do this without asking the user to re-auth?
 2. If yes, if the user does not successfully authenticate using the
    secondary factor, is it possible to hold the current session valid
    so that they can perform regular actions/tasks that don’t require
    elevated authentication?
 3. Is there any place in the SAML spec that you could point me to for 
this?
 4. Would it be easy to maintain deeplinks and send the user back to the
    right page after they authenticate? How would that work for IdP
    initiated SAML?
 5. Would this work for both SP and IdP initiated SAML?

Look forward to hearing from you.

Regards,

Archana