Wim De Clercq wrote:
>
> Hi Oleg,
>
> Would you use SSL with client authentication or would you use SSL only for
> confidentiality (and server authentication)? I assume you would not use SSL
> for authentication.
>
> Also, I can see how you can use an x.509 certificate to *obtain* a
> credential, but I do not understand how it can be used as a credential.
> Getting a credential involves the use of the corresponding private key, no?
>
In our case, we used a system which was kind of the opposite of this -
We had an initial logon module which used password authentication (or
whatever). As part of the authentication protocol, the client would
generate a key pair and submit this (effectively a certificate
request), the security server would generate a certificate for this
client with a limited validity period (using the standard x.509
attributes), and the client could use this to authenticate itself to
other distributed servers in the system (of which there were too many -
didn't have app servers then :-). Thereafter the security context would
be maintained between them using cached tokens. The message buffers
were protected for methods which required this using public
key/symmetric encryption with the generated key pairs, and could be
signed etc. or have sequence numbers inserted in the context to prevent
replay attacks (effectively a roll-your-own SSL style protocol but only
for methods which required protection). In retrospect it was all far
too complicated, but an excellent learning experience (and good fun
compared with a lot of projects I've worked on :-).
> On the systems I have worked on, a SecurityService would hand out a token
> after password verification. The token contains the name of the user and an
> expiration time, all in encrypted form. This token is then sent with every
> request as part of the (IIOP) context information. The app server asks the
> SecurityService to verify the token for every operation. This verification
> only requires a decryption of the token to obtain the user name and
> expiration time. When the token is valid, a new token is made with a later
> expiration date and updated in the context.
> This approach is stateless and after a configurable period of user
> inactivity, the token becomes invalid an a new login is required. What do
> you think about this?
>
This sounds very similar to the system we came up with, except that the
validity period was decided by the security service when it issued the
certificate.
> I am going to use this opportunity to thank you and your colleagues for your
> impressive work.
>
I'll second that (said it before, but no harm in saying it again :-),
Luke.
--
Luke Taylor.
PGP Key ID: 0x57E9523C
