On Fri, 2016-02-26 at 09:00 +0100, Martin Kosek wrote: > On 02/25/2016 10:51 PM, Simo Sorce wrote: > > > > On Thu, 2016-02-25 at 16:13 -0500, Nathaniel McCallum wrote: > > > > > > On Thu, 2016-02-25 at 12:19 -0500, Nathaniel McCallum wrote: > > > > > > > > On Thu, 2016-02-25 at 10:49 -0500, Simo Sorce wrote: > > > > > > > > > > > > > > > On Thu, 2016-02-25 at 10:32 -0500, Nathaniel McCallum wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 2016-02-24 at 09:55 -0500, Nathaniel McCallum > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, 2016-02-21 at 20:50 -0500, Simo Sorce wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, 2016-02-21 at 20:20 -0500, Nathaniel McCallum > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/npmccallum/freeipa/pull/1 > > > > > > > > > > > > > > > > > > The above (pseudo) pull request contains four patches > > > > > > > > > against > > > > > > > > > FreeIPA > > > > > > > > > to enable the insertion of Authentication Indicators > > > > > > > > > into > > > > > > > > > Kerberos > > > > > > > > > tickets. The basic flow looks like this. > > > > > > > > > > > > > > > > > > First, we patch ipa-pwd-extop to return a control > > > > > > > > > indicating > > > > > > > > > what > > > > > > > > > authentication method succeeded resulting in a > > > > > > > > > successful > > > > > > > > > bind. > > > > > > > > > > > > > > > > > > Second, we patch ipa-otpd to check the returned > > > > > > > > > control to > > > > > > > > > ensure > > > > > > > > > that > > > > > > > > > the bind resulted from an otp validation. > > > > > > > > > > > > > > > > > > Third, we patch ipa-kdb to enable the KDC to return > > > > > > > > > either > > > > > > > > > the > > > > > > > > > encrypted timestamp or encrypted challenge preauth > > > > > > > > > mechanism > > > > > > > > > when > > > > > > > > > the > > > > > > > > > user is configured for optional 2FA logins. Clients > > > > > > > > > can > > > > > > > > > then > > > > > > > > > decide > > > > > > > > > whether to do 1FA or 2FA login (for kinit, sane > > > > > > > > > behavior > > > > > > > > > already > > > > > > > > > exists). > > > > > > > > > > > > > > > > > > Forth, we patch ipa-kdb again to insert hard-coded > > > > > > > > > authentication > > > > > > > > > indicators for either OTP or RADIUS. > > > > > > > > > > > > > > > > > > Some explanation is required for the first two > > > > > > > > > patches. > > > > > > > > > Currently, > > > > > > > > > it > > > > > > > > > is possible to do a 1FA through the otp > > > > > > > > > preauthentication > > > > > > > > > mechanism > > > > > > > > > if > > > > > > > > > the user is configured for doing optional 2FA. > > > > > > > > > However, > > > > > > > > > because > > > > > > > > > we > > > > > > > > > want > > > > > > > > > to insert an authentication indicator in this code > > > > > > > > > path, we > > > > > > > > > need > > > > > > > > > to > > > > > > > > > guarantee that a request going through the otp > > > > > > > > > preauth > > > > > > > > > mechanism > > > > > > > > > actually validates an OTP. This is the purpose of the > > > > > > > > > control. > > > > > > > > > > > > > > > > > > Items still on the TODO list: > > > > > > > > > > > > > > > > > > * Authentication Indicator enforcement > > > > > > > > > - Upstream libkrb5 needs to grow funcs for > > > > > > > > > reading > > > > > > > > > indicators > > > > > > > > > - Schema change to add indicators multi-value > > > > > > > > > attr to > > > > > > > > > services > > > > > > > > > - ipa-kdb needs to implement check_policy_tgs() > > > > > > > > > > > > > > > > > > > > > > > > > > > * SSSD needs to learn to handle optional 2FA > > > > > > > > > > > > > > > > > > I will write up a project page for all of this > > > > > > > > > tomorrow. > > > > > > > > > But > > > > > > > > > this > > > > > > > > > small > > > > > > > > > code basically amounts to my brainstorming. It is not > > > > > > > > > ready > > > > > > > > > for > > > > > > > > > merge, > > > > > > > > > just basic review. > > > > > > > > > > > > > > > > > It looks mostly ok, however the LDAP control part needs > > > > > > > > to be > > > > > > > > done > > > > > > > > as > > > > > > > > a > > > > > > > > request/response pair. > > > > > > > > A client that wishes to know what kind of > > > > > > > > authentication > > > > > > > > happened > > > > > > > > should > > > > > > > > send a request control, and only in that case , the > > > > > > > > server > > > > > > > > will > > > > > > > > send > > > > > > > > the > > > > > > > > associated reply control with the requested > > > > > > > > information. > > > > > > > I just pushed a new version of the control (now merged > > > > > > > into a > > > > > > > single > > > > > > > patch): https://github.com/npmccallum/freeipa/commit/a781 > > > > > > > 91ee5d > > > > > > > 31 > > > > > > > e1de > > > > > > > 39 > > > > > > > f28eb637f66199da7e9225 > > > > > > > > > > > > > > In this version the client sends a critical control with > > > > > > > no > > > > > > > content > > > > > > > indicating that the server must validate an OTP. If the > > > > > > > LDAP > > > > > > > server > > > > > > > doesn't support the control (for whatever reason), bind > > > > > > > will > > > > > > > fail. If > > > > > > > the LDAP server doesn't validate an OTP (for whatever > > > > > > > reason), > > > > > > > bind > > > > > > > will fail. > > > > > > > > > > > > > > This approach is simpler and doesn't require a > > > > > > > request/response > > > > > > > control > > > > > > > pair. > > > > > > I need some design advice. My goal here is that we need a > > > > > > way to > > > > > > expose > > > > > > the authentication indicators to services in the FreeIPA > > > > > > UI/CLI. > > > > > > > > > > > > Here is the good news: users can already set these values > > > > > > in > > > > > > FreeIPA > > > > > > using kadmin. They do this by simply setting the > > > > > > require_auth > > > > > > string on > > > > > > the target service principal. Our kdb plugin then encodes > > > > > > these > > > > > > with > > > > > > the rest of the tl_data into the krbExtraData attribute. > > > > > > > > > > > > I see two approaches here. First, we can try to manipulate > > > > > > the > > > > > > krbExtraData attribute directly. Second, we can create a > > > > > > separate > > > > > > attribute for the authentication indicator strings and then > > > > > > synthesize > > > > > > the tl_data internally in kdb. We would have to do this for > > > > > > both > > > > > > reads > > > > > > and writes so as not to break existing kdb functionality. > > > > > > > > > > > > The trade-off that I see is that the first method > > > > > > complicates the > > > > > > python framework side where the second method complicates > > > > > > the kdb > > > > > > plugin. > > > > > > > > > > > > A third option, which I doubt is even possible, is to use > > > > > > kadmin > > > > > > to > > > > > > manipulate this option rather than modifying LDAP directly. > > > > > > > > > > > > Thoughts? > > > > > We should translate it, we need that to allow to delegate > > > > > access > > > > > only > > > > > to > > > > > the specific attribute via our standard means. > > > > > > > > > > We already do this for other tl_data entries. > > > > > > > > > > The krbExtraData access cannot always be delegated because it > > > > > would > > > > > be > > > > > open ended. also it is really obnoxious to have to manipulate > > > > > ASN.1 > > > > > stuff in the framework. > > > > > > > > > > kadmin could be used at some point, but we'd still want to > > > > > have > > > > > this > > > > > attribute extracted in order to be able to grant access > > > > > control > > > > > individually, as our ACL system and delegation system is more > > > > > fine > > > > > grained than what kadmin can offer. > > > > After discussing this with MIT, Simo and Matt, it seems that > > > > the best > > > > option is to update the (MIT) upstream krbPrincipal objectClass > > > > to > > > > have > > > > a new attribute. The reason for this is twofold. First, it has > > > > upstream > > > > value. Second, we don't have good objectClass to attach the new > > > > attribute to inside FreeIPA. > > > > > > > > So the current plan is that Matt will create a patch for > > > > storing auth > > > > indicators (specifically, the "required_auth" strings) in a new > > > > multi- > > > > value string attribute on krbPrincipal objects. The > > > > get_principal() > > > > KDB > > > > hook will read "required_auth" from krbExtraData or (if > > > > present, > > > > preferred) the new attribute. In turn, the put_principal() KDB > > > > hook > > > > will store "required_auth" in the new attribute. This will > > > > allow the > > > > transparent migration of any data currently stored in > > > > krbExtraData. > > > > > > > > As part of this process, Matt will also refactor > > > > put_principal() into > > > > smaller functions (it is currently 800+ LOC). > > > > > > > > Once we have an attribute in upstream krbPrincipal, we will use > > > > this > > > > attribute exclusively in our KDB plugin. > > > I have started a project page: > > > http://www.freeipa.org/page/V4/AuthenticationIndicators > Thanks Nathaniel! For starters, I moved the page to > http://www.freeipa.org/page/V4/Authentication_Indicators > to make sure the URL is consistent with other pages ;-) > > I also updated the Use Cases and added the User Story I am tracking > with this > feature: > http://www.freeipa.org/page/V4/Authentication_Indicators#Strong_Authe > ntication_on_Selected_System > > > > > > > > > We are still waiting on some details. But the general shape of > > > things > > > is there. Please review. :) > > LGTM so far. > > > > Questions: > > - Should the control specify what kind of auth specifically should > > be > > required ? > > > > - Will it make sense in future to have different strength otp-like > > second factors and have ipa-otpd be able to specify which one it is > > expecting to be validated ? > > > > - Even if ipa-otpd will not grow such a feature, I see this control > > could be useful for pure LDAP auth clients, so perhaps a different > > kind > > of client may want to set this control ? Perhaps one day we can > > have a > > way to do GSSAPI auth and check that the AI on the ldap ticket was > > a 2FA > > and then DS will refuse login if the otp AI was missing on the > > ticket it > > received and the control requires it ? (could be used for the IPA > > UI > > connection to LDAP maybe ?) > It would be also nice to add some graph how the workflows look like. > It may be > something based on Simo's picture he created some time back > (attached).
How's this (attached)?
-- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code