SPNEGO login flow: Enforce SPNEGO by condition

[Chris Phillips]

Thanks Daniel,

Regarding '..If it's OK that all users need to opt-in for SPNEGO once, the
current
implementation should work for you.'

Is this opt-in 'forever' or is it time bound?

>From a risk management standpoint, I hope it's time bound and configurable
so that the amount of risk I want to bear is 'configurable' or at least
evident somewhere. 


On this item:
"If IE gets an SPNEGO request, but Kerberos is not available on the
client (or IE is not configured appropriately), the IdP (Shibboleth)
doesn't get a chance to show an error message. Before returning to
the IdP, IE will show a username/password login window (which would
allow to log in using NTLM instead of Kerberos)."

Uhg! That is ugly..


As I try to better understand things, what is the context of the client in
this case? 
I'm thinking of a case where a user has authenticated to their laptop on
the corporate/institutional network and signs in.
I can see this working just as expected in the flows.

However, the one I think is more challenging is:
User signs into a laptop that has been joined to the AD domain and THEN
attempts to sign in while on the road outside the corporate/institutional
network.  Is this flow able to successfully complete as if it were on the
institutional LAN?

I'm just trying to exercise and understand to what extent that SPNEGO can
work for users and what the requirements or perimeter of utility it
affords an IdP who implements. (e.g. In order for SPNEGO to work must
device be on the institutional LAN somehow?)

Tell me if I am accurate on these statements about SPNEGO's flow :
- SPNEGO can be enabled and users can self opt-in
- said users MUST be on the institution LAN where the KDC is 'reachable'
- the moment users attempt to use SPNEGO outside said network where the
KDC is unreachable, they must use password authentication
- password authentication will be automatically offered in such cases
(regardless of browser)
- users will have to only opt-in once for said behaviour to work (SPNEGO
on LAN, password auth outside LAN)

Am I in the right frame of mind based on the above?

C






On 2015-12-01, 9:25 AM, "dev on behalf of Daniel Lutz"
<dev-bounces at shibboleth.net on behalf of daniel.lutz at switch.ch> wrote:

>On 2015-12-01 at 14:23, Chris Phillips wrote:
>> As you call out the IE experience, you are essentially offering the user
>> to either click 'login with password' OR 'login with Kerberos
>> credentials'(or some friendlier variation of text) right?
>
>Yes, that's true. The Password login flow can be configured to provide
>the SPNEGO login as an alternative login method. With this
>configuration, the Password login page still shows the fields for
>username/password login, but additionally shows an "SPNEGO" button. If
>the user clicks on the SPNEGO button, control is passed to the
>SPNEGO login flow, which then runs SPNEGO. If SPNEGO succeeds,
>authentication has finished. If SPNEGO fails, control is passed back
>to the Passwod login flow (i.e. the login page is show again).
>
>> What's the behaviour once the IE user has chosen SPNEGO method for sign
>>on
>> at least once?
>> Will they have been tagged with a cookie to indicate this selection for
>> the duration of the shibboleth session? Duration of the lifetime of a
>> cookie? (days/weeks?)
>
>Before clicking on the SPNEGO button, the user can optionally enable
>"auto-login". This sets a corresponding permanent cookie (by default,
>this cookie has a lifetime of one year). Whenever the user logs in the
>next time, SPNEGO is automatically run (i.e. the Password login page is
>not shown anymore). (In case SPNEGO fails, the cookie is deleted again,
>and the user is redirected to the Password login.)
>
>All of this actually already works with IdP 3.2. Users can opt-in for
>SPNEGO on the Password login page and activate the auto-login feature,
>so that SPNEGO is automatically run next time they log in.
>
>If it's OK that all users need to opt-in for SPNEGO once, the current
>implementation should work for you.
>
>The use case that's addressed in this thread is to automatically run
>SPNEGO for Firefox and Safari users without requiring them to opt-in,
>but to still require IE users to opt-in.
>
>> An area I'm  hopeful this use case will help is Sharepoint SAML
>> integration when using the office apps (powerpoint/word/excel) as the
>>user
>> signs in (password) via a browser, then launches these apps and then
>>forms
>> authentication kicks in again and the user signs in again with password.
>> I agree it's as if they changed browsers midstream but I'm hopeful that
>> with SPNEGO login we can at least see the 'use kerberos credentials'
>> button if not just automatically use it.  My reservation though is that
>> these office apps are going to appear equivalently to IE and therefore
>>not
>> have as graceful behaviour as the first use case which reliably detect
>> failures.
>
>I'm not sure, but I think that the current functionality of the SPNEGO
>login flow is already useful for this case. The only limitation is
>that users need to opt-in for SPNEGO once.
>
>> BTW, what happens in a failed SPNEGO detection state that IE has?  Does
>>it
>> show an error page in Shibboleth?  If so -- maybe one could tweak that
>> page to improve the user flow -- but maybe you've already thought about
>> that?
>
>If IE gets an SPNEGO request, but Kerberos is not available on the
>client (or IE is not configured appropriately), the IdP (Shibboleth)
>doesn't get a chance to show an error message. Before returning to
>the IdP, IE will show a username/password login window (which would
>allow to log in using NTLM instead of Kerberos).
>
>-- Daniel
>
>-- 
>To unsubscribe from this list send an email to
>dev-unsubscribe at shibboleth.net