MCB and Kerberos NEGOTIATE

[Wessel, Keith]

Of course, if you went with #1, you'd hit upon what I'm up against: the fact that remote_user can't intelligently support things like forced reauthentication... unless you can just have a very short Kerberos ticket lifetime.

Keith


From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of David Langenberg
Sent: Friday, April 25, 2014 11:07 PM
To: Shib Users
Subject: Re: MCB and Kerberos NEGOTIATE

1 sounds viable.  Duo, I believe, can strip the @ad.example.edu<http://ad.example.edu> from the principal on their end so that would save you a step.

Dave

On Fri, Apr 25, 2014 at 9:32 PM, Rich Graves <rgraves at carleton.edu<mailto:rgraves at carleton.edu>> wrote:
Muttering to myself:
> Has anyone looked into making (something like) the switch.ch<http://switch.ch> Kerberos authentication plugin work within the MCB framework, in place of the bronze-level username/password?
Well, I don't have either working yet, but possible strategies include:

1) Use the MCB RemoteUser submodule, with /Authn/MCB/RemoteUser protected by mod_auth_kerb. I would need to strip the @AD.EXAMPLE.EDU<http://AD.EXAMPLE.EDU> from the REMOTE_USER variable, but it might work, including Duo second factor as needed.

2) Use the SWITCH Kerberos module, which I think can be installed in the same server as MCB. Not desirable because it would seem to require each SP to specify context and there's no possibility of requiring Duo second factor.

Is #1 a viable strategy?
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>



--
David Langenberg
Identity & Access Management
The University of Chicago
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140426/da08e8d8/attachment.html