RE: SAML + Step up

[Hal Lockhart <hal.lockhart@oracle.com>]

Thank you for your interest.

I am pleased to answer your questions as well as I can. There is also a mailing list (saml-dev@lists.oasis-open.org) 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:archana.ramamoorthy@gmail.com]
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