On 05/30/2012 01:21 PM, Dmitri Pal wrote:
> On 05/30/2012 04:39 PM, Erinn Looney-Triggs wrote:
>> On 05/30/2012 12:13 PM, Dmitri Pal wrote:
>>> On 05/30/2012 03:44 PM, Erinn Looney-Triggs wrote:
>>>> I have for a while had an interest in integrating Google's two
>>>> auth (https://code.google.com/p/google-authenticator/
) into my
>>>> environment. However, the code Google gives is close but not there for a
>>>> centralized auth setup.
>>>> Now there are other projects to deal with this like totp-cgi
) which relies on another PAM module
>>>> However, it seems to me that SSSD might be an appropriate place for
>>>> something like this, so I wanted to gather some thoughts on the
>>>> feasibility of integrating two factor auth into SSSD.
>>>> Let me lay out my idea here, and open it up to criticism.
>>>> Essentially Google authenticator uses a shared secret that is held both
>>>> on the authenticating system and on the device (your cell phone). This
>>>> shared secret then has a bit of magic run on it
) and if what the user enters and
>>>> what is computed match, you are good to go.
>>>> It seems to me that it would be very easy to centrally store this shared
>>>> secret (as well as some emergency codes that are generated in case you
>>>> lose your phone) in LDAP then retrieve it using SSSD (thus allowing
>>>> offline caching). The problem is that the shared secret is, well plain
>>>> text, and sensitive, I don't know if there are ways to mitigate this
>>>> not. Is there a secure storage for something like this?
>>>> Second question is, would SSSD be an appropriate use of this, and if so,
>>>> is it easy to work into the PAM stack to have this as a second prompt,
>>>> Let me know your thoughts, concerns, etc.
>>> Here is what were thinking about:
>>> Replace PAM box on the diagram with SSSD and you will get the picture.
>>> The benefit is that you get a kerberos ticket as a result of the 2FA.
>>> Will this meet your needs?
>> Thanks Dmitri.
>> If I am understanding this correctly, the place then for a plugin and
>> interface to the google auth shared secret would be on the KDC? Which at
>> that point could call out to anywhere and do what it needs to do.
>> I assume the channel for passing information back would be encrypted and
>> authenticated using kerberos from the client to the KDC?
>> Do you have any more docs or info on how this all is put together?
> Here is the code http://git.fedorahosted.org/git/?p=AuthHub.git;a=summary
> Authub is a plugin to the KDC. It communicates with the back end
> processes over the local domain socket.
> The back ends are implemented in python, there are several of them
> The totp one supports the Google authenticator.
> There are two calls that back end needs to implement getTokenInfo - this
> returns to the authhub and KDC information about what the user should be
> prompted for and then verifyRequest to verify what the user replied with.
> These back ends can do the work themselves or proxy the authentication
> to another server using a protocol that that server supports. The
> security of that communication is based on the attributes of the
> protocol. For example yubikey has its own protocol. RADIUS is another one.
> The flow is the following.
> 1) Client sends to the server a request
> 2) KDC gets request and calls authhub plugin
> 3) Authhub plugin enumerates available back ends that can be used for
> this user (principal). This part needs to be implemented as currently
> there is not DB/policy layer to authhub
> 4) Authhub asks the back ends what user should be prompted for rpc call
> 5) AuthHub creates a list of the token info structures and KDC sends
> them to the client
> 6) An appropriate method is chosen on the client side (this is the
> tricky part we are investigating now - which one to choose? how? what is
> the user experience?)
> 7) User is prompted
> 8) User provides the requested info
> 9) Client sends it to the KDC
> 10) KDC passes it to authhub
> 11) AuthHub calls RPC call into the bach end that corresponds to the
> token info that was chosen
> 12) Back end executes verifyRequest() - can send it to a different server
> 13) The verifyRequest() returns success, failure or more (not supported
> for now)
> 14) AuthHub passes status to KDC
> 15) In the case of success a TGT is created
> 16) The result is sent to client
> 17) User is authenticated (or not) and TGT is delivered
> There are several areas that require work so if you are interested in
> helping let me know and we can drill down into more details.
> a) Server side DB layer: DB driver, storage, management tools
> b) Client side prompting and selection - this is complex and requires
> more thinking we can probably publish our current thoughts about it if
> anyone is interested.
>> In short, yes it looks promising, thanks for the pointer.
Hmm ok, thanks for the pointers this is some interesting stuff.
Just my off the cuff assessment here on the client side experience but
it looks a lot like you are starting to replicate a lot of what PAM does
in SSSD (or will need to to create the 2fa user experience). Is there a
way to leverage PAM to create that user experience, or am I missing
large chunks of the overall picture?
I do not think PAM renders itself well for what we are trying to do here.
Authentication back ends need to make a decision about what to prompt
user for. This data is known to the KDC and passed over the RPC using
JSON. There is no way to convey it via PAM interface. Also PAM would
require loading back ends into the memory of KDC. You really do not want
the back end error/core to bring the KDC down. If the back end dies it
will be restarted automatically on the next request.
These are just couple reasons why. I remember there have been more but I
do not recall them. The RPC mechanism with separate back end processes
seems to be most logical architecture.
sssd-devel mailing list
Sr. Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?