Re: [basedb-devel] Programmatic login using a token
Hi Nicklas, Thanks for the suggestions. Maybe I am missing something but wouldn't it be possible to send the username and password to the STS as part of the BASE login? Or, use an empty password string? I should have explained the use case better. It does not relate to the manual login to BASE using the web interface where one types in a username and password. For this we have already implemented and set up an authentication plugin that sends the username and password typed in by a user to the STS service for verification (just like you suggest). Now I am planning to enable programmatic access to BASE (via Web services) from another system that shares identity management (STS) with BASE. The idea is that the user that is logged in to any of these, has obtained a token and is able to access his/her resources in the other system without any further authentication, using only the token (single sign-on). In this federated authentication system one application will be able to automatically integrate resources available to a user in several distinct systems. Since the common authentication mechanism will be based on tokens, I don't expect an application to provide a username/password pair anytime when it needs to access resources hosted in a different system. Currently all the login methods in BASE are username/password oriented, but with the minor change I suggest, it could be easily extended to cover token-like objects as well. At least in programmatic access scenarios, but I can't see a need for any other. I am not sure if I got your suggestion with empty password right, so correct me if I am wrong. The token is not a simple string (it is actually a little XML document), and passing it as a username (with empty password) to the authenticator plugin would not be a nice solution. In any case, I am not sure that supplying a TokenAuthenticator object as a parameter to the login method is a good idea, since it would be very easy to to provide an implementation that just accept anything. I was thinking similarly, but how does it differ from supplying a login method in an authenticator plugin? That method could accept anything as well. Access to SessionControl.login(Token, TokenAuthenticator) operation in only from the code deployed together with BASE server (in my case in implementation of Web services deployed within BASE), so an environment that a BASE administrator should have full control over. The same as external authentication plugins. Pawel Nicklas Nordborg wrote: On 2011-07-26 22:47, Pawel Sztromwasser wrote: Hello BASE team! Extending a little on our recent developments regarding external authentication in BASE [1], I am working now on a Web service interface to BASE that will authenticate users based on secure tokens issued by a trusted STS. The STS authenticates users with username and password, and issues a crypted token confirming their credentials. The token is valid for a limited time and can be used for authentication in applications and services that trust the STS. The STS token does not contain a password, only a user id, so with current implementation of SessionControl I was unable to log in. I added one method to the SessionControl class (see attached diff), included a TokenAuthenticator interface (attached), and everything worked nice. The extra operation allows to log in using a single token object and a validator that can verify the token. The operation contains substantial parts of SessionControl.verifyUserExternal(), which can be extracted to a separate method. The TokenAuthenticator interface and original Authenticator interface are also quite similar, so they could maybe share a common ancestor. I know that the change is in the heart of BASE, but it is little and would provide additional way of programmatic interaction with BASE. If they pass the tests, could you consider including the changes to the BASE codebase? Thanks for the suggestions. Maybe I am missing something but wouldn't it be possible to send the username and password to the STS as part of the BASE login? Or, use an empty password string? In any case, I am not sure that supplying a TokenAuthenticator object as a parameter to the login method is a good idea, since it would be very easy to to provide an implementation that just accept anything. There are also some plans to change the authentication as part of BASE 3 development (http://base.thep.lu.se/ticket/1599). There is not much information since we haven't been thinking very much about this and at the moment I am not sure if we will have time to do it before releasing BASE 3. It depends a bit on when some of the other BASE 3 features are needed in production. I'll keep a link to this thread so that we don't forget it. /Nicklas -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask
Re: [basedb-devel] Programmatic login using a token
On 2011-08-01 10:51, Pawel Sztromwasser wrote: Hi Nicklas, Thanks for the suggestions. Maybe I am missing something but wouldn't it be possible to send the username and password to the STS as part of the BASE login? Or, use an empty password string? I should have explained the use case better. It does not relate to the manual login to BASE using the web interface where one types in a username and password. For this we have already implemented and set up an authentication plugin that sends the username and password typed in by a user to the STS service for verification (just like you suggest). Now I am planning to enable programmatic access to BASE (via Web services) from another system that shares identity management (STS) with BASE. The idea is that the user that is logged in to any of these, has obtained a token and is able to access his/her resources in the other system without any further authentication, using only the token (single sign-on). In this federated authentication system one application will be able to automatically integrate resources available to a user in several distinct systems. Since the common authentication mechanism will be based on tokens, I don't expect an application to provide a username/password pair anytime when it needs to access resources hosted in a different system. Currently all the login methods in BASE are username/password oriented, but with the minor change I suggest, it could be easily extended to cover token-like objects as well. At least in programmatic access scenarios, but I can't see a need for any other. Ok, I understand that this is a bit different than the usual login procedure. But I think there is also already another possible way to solve this. It could be done in a similar way that we are doing with the job agents. They use a master user account with a known username+password that is used to login to BASE. The account should have the Act as another user permissions assigned to a role (eg. just as the Job agent role that is pre-installed in BASE). Then the SessionControl.impersonateLogin() can be used to login as any user without having to provide a password. You'll have to find the internal id of the user but that is more or less the same thing that is done in the diff for SessionControl that you posted in the original post. In any case, I am not sure that supplying a TokenAuthenticator object as a parameter to the login method is a good idea, since it would be very easy to to provide an implementation that just accept anything. I was thinking similarly, but how does it differ from supplying a login method in an authenticator plugin? That method could accept anything as well. Access to SessionControl.login(Token, TokenAuthenticator) operation in only from the code deployed together with BASE server (in my case in implementation of Web services deployed within BASE), so an environment that a BASE administrator should have full control over. The same as external authentication plugins. The difference is that the administrator sets up the authenticator to use in the configuration files and it is not possible for the calling code to change this. Ok, some mean code could probably get around this, so it is good to have control over the server environment. Despite this, I think the public BASE api shouldn't provide this kind of flexibility. I would prefer a solution where the administrator can setup exactly how the authentication should happen. /Nicklas -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ basedb-devel mailing list basedb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/basedb-devel
Re: [basedb-devel] Programmatic login using a token
See my short replies inline. Nicklas Nordborg wrote: On 2011-08-01 10:51, Pawel Sztromwasser wrote: Hi Nicklas, Thanks for the suggestions. Maybe I am missing something but wouldn't it be possible to send the username and password to the STS as part of the BASE login? Or, use an empty password string? I should have explained the use case better. It does not relate to the manual login to BASE using the web interface where one types in a username and password. For this we have already implemented and set up an authentication plugin that sends the username and password typed in by a user to the STS service for verification (just like you suggest). Now I am planning to enable programmatic access to BASE (via Web services) from another system that shares identity management (STS) with BASE. The idea is that the user that is logged in to any of these, has obtained a token and is able to access his/her resources in the other system without any further authentication, using only the token (single sign-on). In this federated authentication system one application will be able to automatically integrate resources available to a user in several distinct systems. Since the common authentication mechanism will be based on tokens, I don't expect an application to provide a username/password pair anytime when it needs to access resources hosted in a different system. Currently all the login methods in BASE are username/password oriented, but with the minor change I suggest, it could be easily extended to cover token-like objects as well. At least in programmatic access scenarios, but I can't see a need for any other. Ok, I understand that this is a bit different than the usual login procedure. But I think there is also already another possible way to solve this. It could be done in a similar way that we are doing with the job agents. They use a master user account with a known username+password that is used to login to BASE. The account should have the Act as another user permissions assigned to a role (eg. just as the Job agent role that is pre-installed in BASE). Then the SessionControl.impersonateLogin() can be used to login as any user without having to provide a password. You'll have to find the internal id of the user but that is more or less the same thing that is done in the diff for SessionControl that you posted in the original post. Ahhh, clever. And no change to BASE required. It looks promising, I will give it a try. In any case, I am not sure that supplying a TokenAuthenticator object as a parameter to the login method is a good idea, since it would be very easy to to provide an implementation that just accept anything. I was thinking similarly, but how does it differ from supplying a login method in an authenticator plugin? That method could accept anything as well. Access to SessionControl.login(Token, TokenAuthenticator) operation in only from the code deployed together with BASE server (in my case in implementation of Web services deployed within BASE), so an environment that a BASE administrator should have full control over. The same as external authentication plugins. The difference is that the administrator sets up the authenticator to use in the configuration files and it is not possible for the calling code to change this. Ok, some mean code could probably get around this, so it is good to have control over the server environment. Despite this, I think the public BASE api shouldn't provide this kind of flexibility. I would prefer a solution where the administrator can setup exactly how the authentication should happen. Fair enough. /Nicklas -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ basedb-devel mailing list basedb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/basedb-devel attachment: pawel_sztromwasser.vcf-- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ basedb-devel mailing list basedb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/basedb-devel
