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?
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?
I am going to use this opportunity to thank you and your colleagues for your
impressive work.
Wim
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Oleg Nitz
> Sent: woensdag 24 januari 2001 23:31
> To: jBoss Developer
> Subject: Re: [jBoss-Dev] Re: [jBoss-User] jaas
>
>
> Hi Mark and Luke,
>
> I can't tell you in details how proxy works, better ask Rickard or
> Dan, I just know that Principal and Credential set on client are
> attached to each method invocation. The Credential is Object, in
> particular it can contain x.509 certificates obtained from a single
> authentication server, or whatever else you want, not necessarily a
> user password.
> Yes, you can decrease the network traffic by making server stateful,
> but for me such schemes are either much more complicated or less
> secure.
> IMHO the best alternative, which is worth implementing in JBoss is
> SSL RMI connections.
> With JAAS the authenticated pairs (username, credential) are cached,
> so the validation is performed on the first call only.
>
> Oleg
>
> On Wednesday 24 January 2001 23:36, marc fleury wrote:
> > |Does this mean that the client has to supply its credentials for
> > | each invocation and that they also have to be re-validated by the
> > | authentication mechanism every time? If so, is this not a
> > | substantial per-call overhead compared to the situation where the
> > | server maintains some state to represent the security context?
> > |
> > |I'm not very familiar with JAAS and so on and would like to get
> > | some idea of how the security in Jboss is put together, if
> > | someone could recommend where to begin. I have some previous
> > | experience of working with CORBA style security. In the system we
> > | were developing the client would logon using a single
> > | authentication server which would issue it with identity and
> > | privilege credentials (x.509 certificates with suitable
> > | extensions) which it would use to access other distributed
> > | servers. The secure associations would be maintained using
> > | tokens, so in this case each server had to maintain state for its
> > | clients - the client-side interceptor would just supply the token
> > | each time in the security context part of the iiop message and
> > | the corresponding server side interceptor would check it against
> > | its cache.
> >
> > yes, ok. Let me be more precise.
> >
> > (I have not worked with JAAS directly or in the implementation of
> > the current LoginModule done by Oleg)
> >
> > I was talking about what JBoss does and propagate in the message
> > generation. The proxy code on the client can extract whatever it is
> > that you use to signify your authenticated status.
> >
> > Now if your code requires to extract a Security Propagation Context
> > that wraps the token or whatever then you need to specify that code
> > in the client proxy.
> >
> > The codebase is modular even in that way. In the sense that the
> > invocation layer can build a proxy based on whatever need (remember
> > static compilation of stubs is Baaaaad, mmmkey?).
> >
> > I don't know that we have the code to externalize that information
> > (tell the stack to use an instance of this to wrap in the proxy by
> > way of some contextual XML information).
> >
> > I recommend taking a peak at what we do in the "straight JRMP1.3"
> > and how we branch to 1.2.2 if needed. I believe it is done with
> > extensions of the base classes which.. blah... maybe we could fully
> > parametrize this class, I don't know.
> >
> > Then take a look at the proxy classes sent to the client and that
> > is where you code your "own propagation". The way the default
> > proxies are coded for security ? I don't know I haven't taken a
> > look at it. Oleg? any input?
> >
> >
> > marc
> >
> > |Just curious,
> > |
> > |Luke.
> > |
> > |--
> > | Luke Taylor.
> > | PGP Key ID: 0x57E9523C
>
>
