| Re: [higgins-dev] Design review on Auth Service |
Hello Paul,
I think we don't need to store "selector public key" on AuthService. It may be more secure if client generates new selector key pair each time before start authentication process (session key pair). LICS is c++ application, key pair generation with openssl takes less one second.
## I don’t see why this is more secure, but I’m probably missing something. But at least we agree that the selector “serial number” must not be gettable or guessable by an attacker.
AuthService have to verify username, hash-of-password and serial number for authenticating, if credentials are valid, AuthService generate access token which includes data needed for Higgins services (Cardsync, AttributeService, etc ) at least userId and "selector public key". This token must be signed with AuthService x509 certificate.
## yes.
So Higgins services will be able to validate token signature and associate userid and "selector public key" for current session. AuthService also may/have to encrypt access token by using selector public key. So selector have to decrypt this token before including in request for obtaining session token. Request to a Higgins service (CardSync, AttributeService, etc) must be signed by using "selector private key" and must be encrypted by using x509 certificate of Higgins service, or delivered over ssl connection. So Higginse service have to validate "request signature" and "access token signature". The response ("session token") must be encrypted by using "selector public key" (service takes it from access token).
Client (lics) may send the same access token to all Higgins services, but "session token" will be associated with corresponding service.
Are you agree?
## Yes. I’m in a conference at the moment. Can you please update the Higgins wiki appropriately?
I don't understand why selector have to store and check assword hash ( http://wiki.eclipse.org/Authentication_Service_1.1#Authenticating_the_user )?
## You can make a distinction between between authenticating the user to the selector vs. authenticating selector & user to the auth service. The selector’s job is to verify that the correct/same human user is using the selector. Remember, we want to be able to use the selector offline (not just online) and still prevent other users who gain physical access to the computer/selector from using the selector. This is why the selector needs to authenticate the user. Theoretically we don’t really need to pass the hash(password) to the auth service. I just thought it might be good to include it—one more thing for the attacker to get/guess.
Just "session token" has idle time, it needs for avoiding out of memory exception. Higgins services (Cardsync, AttributeService, etc) have to store some data (userId, selector public key) associated with session token id in memory and distribute it between installed node (in cluster env).
## good point, please update wiki.
--
thanks,
Alexander Yuhimenko
On Thu, 24 Sep 2009 15:07:39 -0400
Paul Trevithick <ptrevithick@xxxxxxxxx> wrote:
> Alex,
>
> I¹ve tried to capture our latest thinking on the Higgins Auth Service here:
> http://wiki.eclipse.org/Authentication_Service_1.1
>
> Please review/edit/fix that page.
>
> --Paul