Re: [Freeipa-devel] OTP Sync Client Design
On 26.5.2014 18:23, Nathaniel McCallum wrote: On Mon, 2014-05-26 at 09:56 +0200, Jan Cholasta wrote: On 23.5.2014 23:19, Nathaniel McCallum wrote: On Wed, 2014-05-14 at 14:08 -0400, Nathaniel McCallum wrote: Occasionally OTP tokens get out of sync with the server. When this happens, the user or an admin need to synchronize the token. To this end, we landed server-side synchronization support, which is a simple bind with a custom control. This all works with my sample test script. Client support is proving a bit more difficult. In the ideal world, the client would contact LDAP directly and perform the operation. This would make a man in the middle attack difficult and we can ensure encryption over the entire operation. However, browsers, without server-side assistance, cannot perform this operation from javascript. This means that, in this case, the first factor and two second factors must be transmitted to the FreeIPA server and then proxied to 389. Is this an acceptable compromise? This command also needs to be accessible *without* an existing user login since, if a user's token is out of sync, the user can't login. Is it possible to expose such an API? If so, how? Both ipa env and ipa ping seem to require kinit, so I don't see any obvious examples. Thanks everyone for your feedback. This particular feature is proving difficult to implement, even with our agreed upon design. To reiterate this design: there will be an HTTP method by which to synchronize tokens. There are two assumptions in the code which are making this difficult: 1. All cli commands are Command subclasses. 2. All Command subclasses create authenticated server methods. There are thus two ways to tackle this problem. First, I can create a standard POST method in rpcserver.py. This is not very modular. But the biggest problem is that there is no way to create the cli-side command to call it (assumption #1). Well, you could derive the command from ipalib.frontend.Local and manually call the POST method from it. This still creates a (NoOp) server-side RPC method, right? We can probably just accept this as a drawback for now and move on. After a future refactoring of rpcserver.py, we can move the manual POST method into this server-side RPC method. I agree, I think there's no harm in having a placeholder RPC method. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] OTP Sync Client Design
On 05/23/2014 11:19 PM, Nathaniel McCallum wrote: On Wed, 2014-05-14 at 14:08 -0400, Nathaniel McCallum wrote: Occasionally OTP tokens get out of sync with the server. When this happens, the user or an admin need to synchronize the token. To this end, we landed server-side synchronization support, which is a simple bind with a custom control. This all works with my sample test script. Client support is proving a bit more difficult. In the ideal world, the client would contact LDAP directly and perform the operation. This would make a man in the middle attack difficult and we can ensure encryption over the entire operation. However, browsers, without server-side assistance, cannot perform this operation from javascript. This means that, in this case, the first factor and two second factors must be transmitted to the FreeIPA server and then proxied to 389. Is this an acceptable compromise? This command also needs to be accessible *without* an existing user login since, if a user's token is out of sync, the user can't login. Is it possible to expose such an API? If so, how? Both ipa env and ipa ping seem to require kinit, so I don't see any obvious examples. Thanks everyone for your feedback. This particular feature is proving difficult to implement, even with our agreed upon design. To reiterate this design: there will be an HTTP method by which to synchronize tokens. There are two assumptions in the code which are making this difficult: 1. All cli commands are Command subclasses. 2. All Command subclasses create authenticated server methods. There are thus two ways to tackle this problem. First, I can create a standard POST method in rpcserver.py. This is not very modular. But the biggest problem is that there is no way to create the cli-side command to call it (assumption #1). Second, I can create a Command subclass, similar to the passwd plugin. This will create both the client- and server-side components. However, there is no way to disable the server-side authentication. I think that solving the second of these problems is the most reusable. Just as an example, the ping command currently requires authentication but does not need to do so. The passwd Command too shouldn't need to authenticate before executing the command because the command authenticates itself. I think it very likely that we are going to have need for other Command subclasses in the future which do not require authentication. However, implementing this approach is rather difficult as it will require a refactoring of rpcserver.py. The code in rpcserver.py contains many layering violations and the class structure is rather unclear (look, for instance, at the different orders in which xmlrpc and jsonrpc classes inherit from their parent classes). The current problem forcing this refactoring is that authentication appears to happen across several different layers, but always before the command to be executed is unmarshalled. We need to invert this order: the command needs to be unmarshalled first in order to determine whether or not authentication is necessary. I don't think that switching this order is practical without constraining authentication to a single layer (or two: session and krb5) late in the request process. Git tells me that lots of people have touched this code, so I'm hoping for good feedback! ;) Alternatively, we could create a way to inject cli commands without having Command subclasses. Isolating these concerns is itself probably a good design choice. Ideally we'd have a structure where the Command class itself inherits from a CLICommand class and a ServerMethod class. But this too will be a massive refactoring, perhaps even bigger than the rpcserver.py refactoring. So, which assumption should we break: #1 or #2? And who wants to help me do it? Also, I am all ears for easier solutions for this feature. Nathaniel Hi Nathaniel, These are all good ideas, it is true that we are sometimes hitting framework limitations which will force to rewrite some parts, Petr Viktorin already have couple of wished refactorings in mind. What you are suggesting sounds as a pretty massive refactorings touching basic framework parts that have not been touched for long years. Refactorings of this scale would take months of planning and execution. Question is, does this use case warrants such big change? AFAIK, we need to solve following use cases: 1) Admin wants to manipulate user's token via Web UI/CLI - easy to do, admin is authenticated and can run any commands 2) User wants to re-synchronize token via Web UI: easy to do, create POST callback and a Web UI page. IMO, Web UI will be the most used synchronization interface for users, it is usually not very frequent operation so Web UI can guide user through the procedure (as compared to plain CLI). 3) User wants to re-synchronize a token via CLI: given the framework is not ready for this kind of
Re: [Freeipa-devel] OTP Sync Client Design
On 23.5.2014 23:19, Nathaniel McCallum wrote: On Wed, 2014-05-14 at 14:08 -0400, Nathaniel McCallum wrote: Occasionally OTP tokens get out of sync with the server. When this happens, the user or an admin need to synchronize the token. To this end, we landed server-side synchronization support, which is a simple bind with a custom control. This all works with my sample test script. Client support is proving a bit more difficult. In the ideal world, the client would contact LDAP directly and perform the operation. This would make a man in the middle attack difficult and we can ensure encryption over the entire operation. However, browsers, without server-side assistance, cannot perform this operation from javascript. This means that, in this case, the first factor and two second factors must be transmitted to the FreeIPA server and then proxied to 389. Is this an acceptable compromise? This command also needs to be accessible *without* an existing user login since, if a user's token is out of sync, the user can't login. Is it possible to expose such an API? If so, how? Both ipa env and ipa ping seem to require kinit, so I don't see any obvious examples. Thanks everyone for your feedback. This particular feature is proving difficult to implement, even with our agreed upon design. To reiterate this design: there will be an HTTP method by which to synchronize tokens. There are two assumptions in the code which are making this difficult: 1. All cli commands are Command subclasses. 2. All Command subclasses create authenticated server methods. There are thus two ways to tackle this problem. First, I can create a standard POST method in rpcserver.py. This is not very modular. But the biggest problem is that there is no way to create the cli-side command to call it (assumption #1). Well, you could derive the command from ipalib.frontend.Local and manually call the POST method from it. Second, I can create a Command subclass, similar to the passwd plugin. This will create both the client- and server-side components. However, there is no way to disable the server-side authentication. I think that solving the second of these problems is the most reusable. Just as an example, the ping command currently requires authentication but does not need to do so. The passwd Command too shouldn't need to authenticate before executing the command because the command authenticates itself. I think it very likely that we are going to have need for other Command subclasses in the future which do not require authentication. However, implementing this approach is rather difficult as it will require a refactoring of rpcserver.py. The code in rpcserver.py contains many layering violations and the class structure is rather unclear (look, for instance, at the different orders in which xmlrpc and jsonrpc classes inherit from their parent classes). The current problem forcing this refactoring is that authentication appears to happen across several different layers, but always before the command to be executed is unmarshalled. We need to invert this order: the command needs to be unmarshalled first in order to determine whether or not authentication is necessary. I don't think that switching this order is practical without constraining authentication to a single layer (or two: session and krb5) late in the request process. Git tells me that lots of people have touched this code, so I'm hoping for good feedback! ;) Alternatively, we could create a way to inject cli commands without having Command subclasses. Isolating these concerns is itself probably a good design choice. Ideally we'd have a structure where the Command class itself inherits from a CLICommand class and a ServerMethod class. But this too will be a massive refactoring, perhaps even bigger than the rpcserver.py refactoring. So, which assumption should we break: #1 or #2? And who wants to help me do it? Also, I am all ears for easier solutions for this feature. I would go for the refactoring, the rpcserver code does indeed need some love. Nathaniel -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] OTP Sync Client Design
On 26.5.2014 09:41, Martin Kosek wrote: On 05/23/2014 11:19 PM, Nathaniel McCallum wrote: On Wed, 2014-05-14 at 14:08 -0400, Nathaniel McCallum wrote: Occasionally OTP tokens get out of sync with the server. When this happens, the user or an admin need to synchronize the token. To this end, we landed server-side synchronization support, which is a simple bind with a custom control. This all works with my sample test script. Client support is proving a bit more difficult. In the ideal world, the client would contact LDAP directly and perform the operation. This would make a man in the middle attack difficult and we can ensure encryption over the entire operation. However, browsers, without server-side assistance, cannot perform this operation from javascript. This means that, in this case, the first factor and two second factors must be transmitted to the FreeIPA server and then proxied to 389. Is this an acceptable compromise? This command also needs to be accessible *without* an existing user login since, if a user's token is out of sync, the user can't login. Is it possible to expose such an API? If so, how? Both ipa env and ipa ping seem to require kinit, so I don't see any obvious examples. Thanks everyone for your feedback. This particular feature is proving difficult to implement, even with our agreed upon design. To reiterate this design: there will be an HTTP method by which to synchronize tokens. There are two assumptions in the code which are making this difficult: 1. All cli commands are Command subclasses. 2. All Command subclasses create authenticated server methods. There are thus two ways to tackle this problem. First, I can create a standard POST method in rpcserver.py. This is not very modular. But the biggest problem is that there is no way to create the cli-side command to call it (assumption #1). Second, I can create a Command subclass, similar to the passwd plugin. This will create both the client- and server-side components. However, there is no way to disable the server-side authentication. I think that solving the second of these problems is the most reusable. Just as an example, the ping command currently requires authentication but does not need to do so. The passwd Command too shouldn't need to authenticate before executing the command because the command authenticates itself. I think it very likely that we are going to have need for other Command subclasses in the future which do not require authentication. It would be useful for `json_metadata` and `i18n` commands. Also I would like to see a global web ui configuration which could be read prior to authentication, e.g., to get allowed authentication methods( we have a ticket to disable forms-based auth). However, implementing this approach is rather difficult as it will require a refactoring of rpcserver.py. The code in rpcserver.py contains many layering violations and the class structure is rather unclear (look, for instance, at the different orders in which xmlrpc and jsonrpc classes inherit from their parent classes). The current problem forcing this refactoring is that authentication appears to happen across several different layers, but always before the command to be executed is unmarshalled. We need to invert this order: the command needs to be unmarshalled first in order to determine whether or not authentication is necessary. I don't think that switching this order is practical without constraining authentication to a single layer (or two: session and krb5) late in the request process. Git tells me that lots of people have touched this code, so I'm hoping for good feedback! ;) Alternatively, we could create a way to inject cli commands without having Command subclasses. Isolating these concerns is itself probably a good design choice. Ideally we'd have a structure where the Command class itself inherits from a CLICommand class and a ServerMethod class. But this too will be a massive refactoring, perhaps even bigger than the rpcserver.py refactoring. So, which assumption should we break: #1 or #2? And who wants to help me do it? Also, I am all ears for easier solutions for this feature. Nathaniel Hi Nathaniel, These are all good ideas, it is true that we are sometimes hitting framework limitations which will force to rewrite some parts, Petr Viktorin already have couple of wished refactorings in mind. What you are suggesting sounds as a pretty massive refactorings touching basic framework parts that have not been touched for long years. Refactorings of this scale would take months of planning and execution. Question is, does this use case warrants such big change? AFAIK, we need to solve following use cases: 1) Admin wants to manipulate user's token via Web UI/CLI - easy to do, admin is authenticated and can run any commands 2) User wants to re-synchronize token via Web UI: easy to do, create POST callback and a Web UI page. IMO, Web UI will be the most used synchronization interface
Re: [Freeipa-devel] OTP Sync Client Design
On Mon, 2014-05-26 at 09:56 +0200, Jan Cholasta wrote: On 23.5.2014 23:19, Nathaniel McCallum wrote: On Wed, 2014-05-14 at 14:08 -0400, Nathaniel McCallum wrote: Occasionally OTP tokens get out of sync with the server. When this happens, the user or an admin need to synchronize the token. To this end, we landed server-side synchronization support, which is a simple bind with a custom control. This all works with my sample test script. Client support is proving a bit more difficult. In the ideal world, the client would contact LDAP directly and perform the operation. This would make a man in the middle attack difficult and we can ensure encryption over the entire operation. However, browsers, without server-side assistance, cannot perform this operation from javascript. This means that, in this case, the first factor and two second factors must be transmitted to the FreeIPA server and then proxied to 389. Is this an acceptable compromise? This command also needs to be accessible *without* an existing user login since, if a user's token is out of sync, the user can't login. Is it possible to expose such an API? If so, how? Both ipa env and ipa ping seem to require kinit, so I don't see any obvious examples. Thanks everyone for your feedback. This particular feature is proving difficult to implement, even with our agreed upon design. To reiterate this design: there will be an HTTP method by which to synchronize tokens. There are two assumptions in the code which are making this difficult: 1. All cli commands are Command subclasses. 2. All Command subclasses create authenticated server methods. There are thus two ways to tackle this problem. First, I can create a standard POST method in rpcserver.py. This is not very modular. But the biggest problem is that there is no way to create the cli-side command to call it (assumption #1). Well, you could derive the command from ipalib.frontend.Local and manually call the POST method from it. This still creates a (NoOp) server-side RPC method, right? We can probably just accept this as a drawback for now and move on. After a future refactoring of rpcserver.py, we can move the manual POST method into this server-side RPC method. Second, I can create a Command subclass, similar to the passwd plugin. This will create both the client- and server-side components. However, there is no way to disable the server-side authentication. I think that solving the second of these problems is the most reusable. Just as an example, the ping command currently requires authentication but does not need to do so. The passwd Command too shouldn't need to authenticate before executing the command because the command authenticates itself. I think it very likely that we are going to have need for other Command subclasses in the future which do not require authentication. However, implementing this approach is rather difficult as it will require a refactoring of rpcserver.py. The code in rpcserver.py contains many layering violations and the class structure is rather unclear (look, for instance, at the different orders in which xmlrpc and jsonrpc classes inherit from their parent classes). The current problem forcing this refactoring is that authentication appears to happen across several different layers, but always before the command to be executed is unmarshalled. We need to invert this order: the command needs to be unmarshalled first in order to determine whether or not authentication is necessary. I don't think that switching this order is practical without constraining authentication to a single layer (or two: session and krb5) late in the request process. Git tells me that lots of people have touched this code, so I'm hoping for good feedback! ;) Alternatively, we could create a way to inject cli commands without having Command subclasses. Isolating these concerns is itself probably a good design choice. Ideally we'd have a structure where the Command class itself inherits from a CLICommand class and a ServerMethod class. But this too will be a massive refactoring, perhaps even bigger than the rpcserver.py refactoring. So, which assumption should we break: #1 or #2? And who wants to help me do it? Also, I am all ears for easier solutions for this feature. I would go for the refactoring, the rpcserver code does indeed need some love. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] OTP Sync Client Design
On Wed, 2014-05-14 at 14:08 -0400, Nathaniel McCallum wrote: Occasionally OTP tokens get out of sync with the server. When this happens, the user or an admin need to synchronize the token. To this end, we landed server-side synchronization support, which is a simple bind with a custom control. This all works with my sample test script. Client support is proving a bit more difficult. In the ideal world, the client would contact LDAP directly and perform the operation. This would make a man in the middle attack difficult and we can ensure encryption over the entire operation. However, browsers, without server-side assistance, cannot perform this operation from javascript. This means that, in this case, the first factor and two second factors must be transmitted to the FreeIPA server and then proxied to 389. Is this an acceptable compromise? This command also needs to be accessible *without* an existing user login since, if a user's token is out of sync, the user can't login. Is it possible to expose such an API? If so, how? Both ipa env and ipa ping seem to require kinit, so I don't see any obvious examples. Thanks everyone for your feedback. This particular feature is proving difficult to implement, even with our agreed upon design. To reiterate this design: there will be an HTTP method by which to synchronize tokens. There are two assumptions in the code which are making this difficult: 1. All cli commands are Command subclasses. 2. All Command subclasses create authenticated server methods. There are thus two ways to tackle this problem. First, I can create a standard POST method in rpcserver.py. This is not very modular. But the biggest problem is that there is no way to create the cli-side command to call it (assumption #1). Second, I can create a Command subclass, similar to the passwd plugin. This will create both the client- and server-side components. However, there is no way to disable the server-side authentication. I think that solving the second of these problems is the most reusable. Just as an example, the ping command currently requires authentication but does not need to do so. The passwd Command too shouldn't need to authenticate before executing the command because the command authenticates itself. I think it very likely that we are going to have need for other Command subclasses in the future which do not require authentication. However, implementing this approach is rather difficult as it will require a refactoring of rpcserver.py. The code in rpcserver.py contains many layering violations and the class structure is rather unclear (look, for instance, at the different orders in which xmlrpc and jsonrpc classes inherit from their parent classes). The current problem forcing this refactoring is that authentication appears to happen across several different layers, but always before the command to be executed is unmarshalled. We need to invert this order: the command needs to be unmarshalled first in order to determine whether or not authentication is necessary. I don't think that switching this order is practical without constraining authentication to a single layer (or two: session and krb5) late in the request process. Git tells me that lots of people have touched this code, so I'm hoping for good feedback! ;) Alternatively, we could create a way to inject cli commands without having Command subclasses. Isolating these concerns is itself probably a good design choice. Ideally we'd have a structure where the Command class itself inherits from a CLICommand class and a ServerMethod class. But this too will be a massive refactoring, perhaps even bigger than the rpcserver.py refactoring. So, which assumption should we break: #1 or #2? And who wants to help me do it? Also, I am all ears for easier solutions for this feature. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] OTP Sync Client Design
- Original Message - Occasionally OTP tokens get out of sync with the server. When this happens, the user or an admin need to synchronize the token. To this end, we landed server-side synchronization support, which is a simple bind with a custom control. This all works with my sample test script. Client support is proving a bit more difficult. In the ideal world, the client would contact LDAP directly and perform the operation. This would make a man in the middle attack difficult and we can ensure encryption over the entire operation. However, browsers, without server-side assistance, cannot perform this operation from javascript. This means that, in this case, the first factor and two second factors must be transmitted to the FreeIPA server and then proxied to 389. Is this an acceptable compromise? This command also needs to be accessible *without* an existing user login since, if a user's token is out of sync, the user can't login. Is it possible to expose such an API? If so, how? Both ipa env and ipa ping seem to require kinit, so I don't see any obvious examples. Sounds to me this should be done via a separate page not from javascript, then you do not have to deal with the chicken-egg issue of framework authentication ... yeah custom code's not great but the problem here seems quite limited to re-synchronization only. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] OTP Sync Client Design
On 15.5.2014 09:52, Simo Sorce wrote: - Original Message - Occasionally OTP tokens get out of sync with the server. When this happens, the user or an admin need to synchronize the token. To this end, we landed server-side synchronization support, which is a simple bind with a custom control. This all works with my sample test script. Client support is proving a bit more difficult. In the ideal world, the client would contact LDAP directly and perform the operation. This would make a man in the middle attack difficult and we can ensure encryption over the entire operation. However, browsers, without server-side assistance, cannot perform this operation from javascript. This means that, in this case, the first factor and two second factors must be transmitted to the FreeIPA server and then proxied to 389. Is this an acceptable compromise? This command also needs to be accessible *without* an existing user login since, if a user's token is out of sync, the user can't login. Is it possible to expose such an API? If so, how? Both ipa env and ipa ping seem to require kinit, so I don't see any obvious examples. Sounds to me this should be done via a separate page not from javascript, then you do not have to deal with the chicken-egg issue of framework authentication ... yeah custom code's not great but the problem here seems quite limited to re-synchronization only. Simo. IMO it should be similar to ipaserver.rpcserver.login_password and change_password methods. Then it could be use from various UIs - main IPA Web UI, separate page, some CLI app... -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] OTP Sync Client Design
On 15.5.2014 00:23, Dmitri Pal wrote: On 05/14/2014 05:49 PM, Nathaniel McCallum wrote: On Wed, 2014-05-14 at 17:35 -0400, Dmitri Pal wrote: On 05/14/2014 05:23 PM, Nathaniel McCallum wrote: On Wed, 2014-05-14 at 16:34 -0400, Dmitri Pal wrote: On 05/14/2014 02:08 PM, Nathaniel McCallum wrote: Occasionally OTP tokens get out of sync with the server. When this happens, the user or an admin need to synchronize the token. To this end, we landed server-side synchronization support, which is a simple bind with a custom control. This all works with my sample test script. Client support is proving a bit more difficult. In the ideal world, the client would contact LDAP directly and perform the operation. This would make a man in the middle attack difficult and we can ensure encryption over the entire operation. However, browsers, without server-side assistance, cannot perform this operation from javascript. This means that, in this case, the first factor and two second factors must be transmitted to the FreeIPA server and then proxied to 389. Is this an acceptable compromise? Does Javascript have a way to encrypt things? May be we should do some encryption before sending the values over the wire? On the other hand we are OK with the form based login so I am not sure if there is any value. Yes, but I agree there is not a lot of value. We might have some logic related to permissions i.e. members of the admin group can only sync on server but I am not sure that is something we should consider out of box. In any way IMO it should be a separate page, other than login page that can be accessed by anyone. It should be visible outside firewall like other OTP vendors do. This would allow to use a mobile device to sync up a token (and potentially change the password). This would be nice. This command also needs to be accessible *without* an existing user login since, if a user's token is out of sync, the user can't login. Is it possible to expose such an API? If so, how? Both ipa env and ipa ping seem to require kinit, so I don't see any obvious examples. IMO SSSD should probably have a way to sync the token. From usability point of view it should be a part of the standard stock client software, not a part of the IPA client or ipa tools. It should probably have a good UI integration too if token is used to login into a laptop. SSSD has direct access to LDAP right? If so, it can just do a bind with the added control. That is actually the easiest way. Trying to access via a third API is probably actually more difficult. So for that to happen we should probably expose this interface over D-BUS. This is what we talked about with the desktop folks some time ago. The attached is the doc and there are diagrams at the end that show what we decided needs to be done. Similar to that one can provide a simple otp-sync application that will sync using command line (but on the other hand may be it should just warp curl?). How exactly we expose this in GDM is indeed a much more complicated question and needs to be part of the next phase of integration. I've CC'd jhrozek for this part. Some thoughts came up while writing this mail: a) We can go the complex path and provide password and sync capabilities in every client. This is a lot of work based on my past experience and can't be done quickly. See the complexity of the diagrams and flows in the attached doc. And may be it should not be. The synchronization needs to be added to whatever layer has access to the LDAP server. How it is exposed from there is specific to each application. b) May be IPA should provide a portal/proxy to do self service token sync and/or password change. This can be a URL. It should be possible to access it externally outside the firewall. It should be bullet proof. But then we need just one interface and one call and we can use it from mobile device or some other system on the internet to self service the token and then pass authentication. IMO that would save us a lot of time and effort. I know other OTP vendors went this path and were quite successful. +1. This solves the VPN bootstrapping problem. However: 1. It should be available by default in the FreeIPA installation with a link from the login page. This is just a matter of product polish. 2. In the case of a user logging into GDM, we have a bootstrapping problem that they can't login without a token, and they can't sync their token without logging into a browser. GDM/SSSD probably needs to support this natively. True but not from day one. This is why I mentioned a mobile device. Keeping in mind that FreeOTP is on the mobile device and there is a good chance that the person who will have a Linux laptop will have a mobile device. They can also call a helpdesk and ask the helpdesk engineer to sync the token for them. That means that there should be an admin interface that would not require the first factor just two codes. Yup. Agreed. Just thinking big picture. Nathaniel
Re: [Freeipa-devel] OTP Sync Client Design
On Wed, May 14, 2014 at 05:23:34PM -0400, Nathaniel McCallum wrote: IMO SSSD should probably have a way to sync the token. From usability point of view it should be a part of the standard stock client software, not a part of the IPA client or ipa tools. It should probably have a good UI integration too if token is used to login into a laptop. SSSD has direct access to LDAP right? If so, it can just do a bind with the added control. That is actually the easiest way. Trying to access via a third API is probably actually more difficult. Yes, SSSD uses the machine's account (the keytab), so whatever info you can read using the machine credentials is avaibale to the SSSD. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] OTP Sync Client Design
Occasionally OTP tokens get out of sync with the server. When this happens, the user or an admin need to synchronize the token. To this end, we landed server-side synchronization support, which is a simple bind with a custom control. This all works with my sample test script. Client support is proving a bit more difficult. In the ideal world, the client would contact LDAP directly and perform the operation. This would make a man in the middle attack difficult and we can ensure encryption over the entire operation. However, browsers, without server-side assistance, cannot perform this operation from javascript. This means that, in this case, the first factor and two second factors must be transmitted to the FreeIPA server and then proxied to 389. Is this an acceptable compromise? This command also needs to be accessible *without* an existing user login since, if a user's token is out of sync, the user can't login. Is it possible to expose such an API? If so, how? Both ipa env and ipa ping seem to require kinit, so I don't see any obvious examples. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] OTP Sync Client Design
On Wed, 2014-05-14 at 16:34 -0400, Dmitri Pal wrote: On 05/14/2014 02:08 PM, Nathaniel McCallum wrote: Occasionally OTP tokens get out of sync with the server. When this happens, the user or an admin need to synchronize the token. To this end, we landed server-side synchronization support, which is a simple bind with a custom control. This all works with my sample test script. Client support is proving a bit more difficult. In the ideal world, the client would contact LDAP directly and perform the operation. This would make a man in the middle attack difficult and we can ensure encryption over the entire operation. However, browsers, without server-side assistance, cannot perform this operation from javascript. This means that, in this case, the first factor and two second factors must be transmitted to the FreeIPA server and then proxied to 389. Is this an acceptable compromise? Does Javascript have a way to encrypt things? May be we should do some encryption before sending the values over the wire? On the other hand we are OK with the form based login so I am not sure if there is any value. Yes, but I agree there is not a lot of value. We might have some logic related to permissions i.e. members of the admin group can only sync on server but I am not sure that is something we should consider out of box. In any way IMO it should be a separate page, other than login page that can be accessed by anyone. It should be visible outside firewall like other OTP vendors do. This would allow to use a mobile device to sync up a token (and potentially change the password). This would be nice. This command also needs to be accessible *without* an existing user login since, if a user's token is out of sync, the user can't login. Is it possible to expose such an API? If so, how? Both ipa env and ipa ping seem to require kinit, so I don't see any obvious examples. IMO SSSD should probably have a way to sync the token. From usability point of view it should be a part of the standard stock client software, not a part of the IPA client or ipa tools. It should probably have a good UI integration too if token is used to login into a laptop. SSSD has direct access to LDAP right? If so, it can just do a bind with the added control. That is actually the easiest way. Trying to access via a third API is probably actually more difficult. So for that to happen we should probably expose this interface over D-BUS. This is what we talked about with the desktop folks some time ago. The attached is the doc and there are diagrams at the end that show what we decided needs to be done. Similar to that one can provide a simple otp-sync application that will sync using command line (but on the other hand may be it should just warp curl?). How exactly we expose this in GDM is indeed a much more complicated question and needs to be part of the next phase of integration. I've CC'd jhrozek for this part. Some thoughts came up while writing this mail: a) We can go the complex path and provide password and sync capabilities in every client. This is a lot of work based on my past experience and can't be done quickly. See the complexity of the diagrams and flows in the attached doc. And may be it should not be. The synchronization needs to be added to whatever layer has access to the LDAP server. How it is exposed from there is specific to each application. b) May be IPA should provide a portal/proxy to do self service token sync and/or password change. This can be a URL. It should be possible to access it externally outside the firewall. It should be bullet proof. But then we need just one interface and one call and we can use it from mobile device or some other system on the internet to self service the token and then pass authentication. IMO that would save us a lot of time and effort. I know other OTP vendors went this path and were quite successful. +1. This solves the VPN bootstrapping problem. However: 1. It should be available by default in the FreeIPA installation with a link from the login page. This is just a matter of product polish. 2. In the case of a user logging into GDM, we have a bootstrapping problem that they can't login without a token, and they can't sync their token without logging into a browser. GDM/SSSD probably needs to support this natively. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] OTP Sync Client Design
On 05/14/2014 05:23 PM, Nathaniel McCallum wrote: On Wed, 2014-05-14 at 16:34 -0400, Dmitri Pal wrote: On 05/14/2014 02:08 PM, Nathaniel McCallum wrote: Occasionally OTP tokens get out of sync with the server. When this happens, the user or an admin need to synchronize the token. To this end, we landed server-side synchronization support, which is a simple bind with a custom control. This all works with my sample test script. Client support is proving a bit more difficult. In the ideal world, the client would contact LDAP directly and perform the operation. This would make a man in the middle attack difficult and we can ensure encryption over the entire operation. However, browsers, without server-side assistance, cannot perform this operation from javascript. This means that, in this case, the first factor and two second factors must be transmitted to the FreeIPA server and then proxied to 389. Is this an acceptable compromise? Does Javascript have a way to encrypt things? May be we should do some encryption before sending the values over the wire? On the other hand we are OK with the form based login so I am not sure if there is any value. Yes, but I agree there is not a lot of value. We might have some logic related to permissions i.e. members of the admin group can only sync on server but I am not sure that is something we should consider out of box. In any way IMO it should be a separate page, other than login page that can be accessed by anyone. It should be visible outside firewall like other OTP vendors do. This would allow to use a mobile device to sync up a token (and potentially change the password). This would be nice. This command also needs to be accessible *without* an existing user login since, if a user's token is out of sync, the user can't login. Is it possible to expose such an API? If so, how? Both ipa env and ipa ping seem to require kinit, so I don't see any obvious examples. IMO SSSD should probably have a way to sync the token. From usability point of view it should be a part of the standard stock client software, not a part of the IPA client or ipa tools. It should probably have a good UI integration too if token is used to login into a laptop. SSSD has direct access to LDAP right? If so, it can just do a bind with the added control. That is actually the easiest way. Trying to access via a third API is probably actually more difficult. So for that to happen we should probably expose this interface over D-BUS. This is what we talked about with the desktop folks some time ago. The attached is the doc and there are diagrams at the end that show what we decided needs to be done. Similar to that one can provide a simple otp-sync application that will sync using command line (but on the other hand may be it should just warp curl?). How exactly we expose this in GDM is indeed a much more complicated question and needs to be part of the next phase of integration. I've CC'd jhrozek for this part. Some thoughts came up while writing this mail: a) We can go the complex path and provide password and sync capabilities in every client. This is a lot of work based on my past experience and can't be done quickly. See the complexity of the diagrams and flows in the attached doc. And may be it should not be. The synchronization needs to be added to whatever layer has access to the LDAP server. How it is exposed from there is specific to each application. b) May be IPA should provide a portal/proxy to do self service token sync and/or password change. This can be a URL. It should be possible to access it externally outside the firewall. It should be bullet proof. But then we need just one interface and one call and we can use it from mobile device or some other system on the internet to self service the token and then pass authentication. IMO that would save us a lot of time and effort. I know other OTP vendors went this path and were quite successful. +1. This solves the VPN bootstrapping problem. However: 1. It should be available by default in the FreeIPA installation with a link from the login page. This is just a matter of product polish. 2. In the case of a user logging into GDM, we have a bootstrapping problem that they can't login without a token, and they can't sync their token without logging into a browser. GDM/SSSD probably needs to support this natively. True but not from day one. This is why I mentioned a mobile device. Keeping in mind that FreeOTP is on the mobile device and there is a good chance that the person who will have a Linux laptop will have a mobile device. They can also call a helpdesk and ask the helpdesk engineer to sync the token for them. That means that there should be an admin interface that would not require the first factor just two codes. Nathaniel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list
Re: [Freeipa-devel] OTP Sync Client Design
On Wed, 2014-05-14 at 17:35 -0400, Dmitri Pal wrote: On 05/14/2014 05:23 PM, Nathaniel McCallum wrote: On Wed, 2014-05-14 at 16:34 -0400, Dmitri Pal wrote: On 05/14/2014 02:08 PM, Nathaniel McCallum wrote: Occasionally OTP tokens get out of sync with the server. When this happens, the user or an admin need to synchronize the token. To this end, we landed server-side synchronization support, which is a simple bind with a custom control. This all works with my sample test script. Client support is proving a bit more difficult. In the ideal world, the client would contact LDAP directly and perform the operation. This would make a man in the middle attack difficult and we can ensure encryption over the entire operation. However, browsers, without server-side assistance, cannot perform this operation from javascript. This means that, in this case, the first factor and two second factors must be transmitted to the FreeIPA server and then proxied to 389. Is this an acceptable compromise? Does Javascript have a way to encrypt things? May be we should do some encryption before sending the values over the wire? On the other hand we are OK with the form based login so I am not sure if there is any value. Yes, but I agree there is not a lot of value. We might have some logic related to permissions i.e. members of the admin group can only sync on server but I am not sure that is something we should consider out of box. In any way IMO it should be a separate page, other than login page that can be accessed by anyone. It should be visible outside firewall like other OTP vendors do. This would allow to use a mobile device to sync up a token (and potentially change the password). This would be nice. This command also needs to be accessible *without* an existing user login since, if a user's token is out of sync, the user can't login. Is it possible to expose such an API? If so, how? Both ipa env and ipa ping seem to require kinit, so I don't see any obvious examples. IMO SSSD should probably have a way to sync the token. From usability point of view it should be a part of the standard stock client software, not a part of the IPA client or ipa tools. It should probably have a good UI integration too if token is used to login into a laptop. SSSD has direct access to LDAP right? If so, it can just do a bind with the added control. That is actually the easiest way. Trying to access via a third API is probably actually more difficult. So for that to happen we should probably expose this interface over D-BUS. This is what we talked about with the desktop folks some time ago. The attached is the doc and there are diagrams at the end that show what we decided needs to be done. Similar to that one can provide a simple otp-sync application that will sync using command line (but on the other hand may be it should just warp curl?). How exactly we expose this in GDM is indeed a much more complicated question and needs to be part of the next phase of integration. I've CC'd jhrozek for this part. Some thoughts came up while writing this mail: a) We can go the complex path and provide password and sync capabilities in every client. This is a lot of work based on my past experience and can't be done quickly. See the complexity of the diagrams and flows in the attached doc. And may be it should not be. The synchronization needs to be added to whatever layer has access to the LDAP server. How it is exposed from there is specific to each application. b) May be IPA should provide a portal/proxy to do self service token sync and/or password change. This can be a URL. It should be possible to access it externally outside the firewall. It should be bullet proof. But then we need just one interface and one call and we can use it from mobile device or some other system on the internet to self service the token and then pass authentication. IMO that would save us a lot of time and effort. I know other OTP vendors went this path and were quite successful. +1. This solves the VPN bootstrapping problem. However: 1. It should be available by default in the FreeIPA installation with a link from the login page. This is just a matter of product polish. 2. In the case of a user logging into GDM, we have a bootstrapping problem that they can't login without a token, and they can't sync their token without logging into a browser. GDM/SSSD probably needs to support this natively. True but not from day one. This is why I mentioned a mobile device. Keeping in mind that FreeOTP is on the mobile device and there is a good chance that the person who will have a Linux laptop will have a mobile device. They can also call a helpdesk and ask the helpdesk engineer to sync the token for them. That means that there should be an admin interface that would not require the first factor
Re: [Freeipa-devel] OTP Sync Client Design
On 05/14/2014 05:49 PM, Nathaniel McCallum wrote: On Wed, 2014-05-14 at 17:35 -0400, Dmitri Pal wrote: On 05/14/2014 05:23 PM, Nathaniel McCallum wrote: On Wed, 2014-05-14 at 16:34 -0400, Dmitri Pal wrote: On 05/14/2014 02:08 PM, Nathaniel McCallum wrote: Occasionally OTP tokens get out of sync with the server. When this happens, the user or an admin need to synchronize the token. To this end, we landed server-side synchronization support, which is a simple bind with a custom control. This all works with my sample test script. Client support is proving a bit more difficult. In the ideal world, the client would contact LDAP directly and perform the operation. This would make a man in the middle attack difficult and we can ensure encryption over the entire operation. However, browsers, without server-side assistance, cannot perform this operation from javascript. This means that, in this case, the first factor and two second factors must be transmitted to the FreeIPA server and then proxied to 389. Is this an acceptable compromise? Does Javascript have a way to encrypt things? May be we should do some encryption before sending the values over the wire? On the other hand we are OK with the form based login so I am not sure if there is any value. Yes, but I agree there is not a lot of value. We might have some logic related to permissions i.e. members of the admin group can only sync on server but I am not sure that is something we should consider out of box. In any way IMO it should be a separate page, other than login page that can be accessed by anyone. It should be visible outside firewall like other OTP vendors do. This would allow to use a mobile device to sync up a token (and potentially change the password). This would be nice. This command also needs to be accessible *without* an existing user login since, if a user's token is out of sync, the user can't login. Is it possible to expose such an API? If so, how? Both ipa env and ipa ping seem to require kinit, so I don't see any obvious examples. IMO SSSD should probably have a way to sync the token. From usability point of view it should be a part of the standard stock client software, not a part of the IPA client or ipa tools. It should probably have a good UI integration too if token is used to login into a laptop. SSSD has direct access to LDAP right? If so, it can just do a bind with the added control. That is actually the easiest way. Trying to access via a third API is probably actually more difficult. So for that to happen we should probably expose this interface over D-BUS. This is what we talked about with the desktop folks some time ago. The attached is the doc and there are diagrams at the end that show what we decided needs to be done. Similar to that one can provide a simple otp-sync application that will sync using command line (but on the other hand may be it should just warp curl?). How exactly we expose this in GDM is indeed a much more complicated question and needs to be part of the next phase of integration. I've CC'd jhrozek for this part. Some thoughts came up while writing this mail: a) We can go the complex path and provide password and sync capabilities in every client. This is a lot of work based on my past experience and can't be done quickly. See the complexity of the diagrams and flows in the attached doc. And may be it should not be. The synchronization needs to be added to whatever layer has access to the LDAP server. How it is exposed from there is specific to each application. b) May be IPA should provide a portal/proxy to do self service token sync and/or password change. This can be a URL. It should be possible to access it externally outside the firewall. It should be bullet proof. But then we need just one interface and one call and we can use it from mobile device or some other system on the internet to self service the token and then pass authentication. IMO that would save us a lot of time and effort. I know other OTP vendors went this path and were quite successful. +1. This solves the VPN bootstrapping problem. However: 1. It should be available by default in the FreeIPA installation with a link from the login page. This is just a matter of product polish. 2. In the case of a user logging into GDM, we have a bootstrapping problem that they can't login without a token, and they can't sync their token without logging into a browser. GDM/SSSD probably needs to support this natively. True but not from day one. This is why I mentioned a mobile device. Keeping in mind that FreeOTP is on the mobile device and there is a good chance that the person who will have a Linux laptop will have a mobile device. They can also call a helpdesk and ask the helpdesk engineer to sync the token for them. That means that there should be an admin interface that would not require the first factor just two codes. Yup. Agreed. Just thinking big picture. Nathaniel So it looks like that we agree
