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.
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.
basedb-devel mailing list