tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack" <jack...@hotmail.com>
Subject a bit info
Date Mon, 23 Jan 2006 03:31:06 GMT
Hi, Mr. Thomas,



Thank your for spending time to send me responses!



I have spent pretty much effort on authentication & authorization, but i 
might still have some misunderstandings.

Thank you for pointing out my wrong ideas!

I might have put too much information in this msg. Be patient.

Either it is good for tomcat, or it is my mistake.



=== about client certificate authentication 
=========================================

"Mark Thomas" <markt@apache.org>

> a) You canNOT not use ssl and ask for client certificates. CLIENT-CERT
> requires the use of ssl.

>> When we use client-cert, we might be not using ssl at all since we don't 
>> ask
>> confidential transfer.
>This is not correct. CLIENT-CERT authentication *requires* ssl.

>ssl is still ssl even if NULL encryption is used.

Yes. We have different opinion here.

I guess that you might think we need ssl to get the certificate from the 
client.

Is this the right reason?



One question here:

when i specify NONE transfer guarantee, but ask for client-cert,

are all the transferred data encrypted or not?



Furthermore, is it possible to get a certificate over a normal http 
connection?

Http doesn't support this directly, but we still can get it.

Form can be used to get username & password, it can also be used to get the 
certificate.

Then client-cert authentication has nothing to do with ssl.

The spec doesn't say how to get the the certificate from a web user.

May I suggest here we just add a new field("j_cert") to form

with action="j_security_check", and enctype="multipart/form-data"

<form method="post" action="j_security_check" enctype="multipart/form-data">

 <input type="file" name="j_cert">

</form>



When field "j_cert" doesn't appear then check "j_username" & "j_password".



In servlet specification, srv 12.5.4 "https client authentication" talks 
about authentication provided by ssl.

And it list auth methos: BASIC, DIGEST, FORM, CLIENT-CERT, or others.

However, it doesn't say client-cert is the authentication provided by ssl.

May we interpret in this way:

client-cert    whatever method to get a certificate, and verify it.

others            ssl can be interpret as one of others.

We should not forget "other" auth method.

authenticators are doing the right job as Callbackhandler in JAAS.



Or we should extend the meaning of "form based authentication".

(This is not my preference since form is just a way to get the credential 
information,

and we don't call basic & digest auth as http embeded authentication.)



Many web users use PGP, web browsers might be not able to access pgp 
keyring.

I want to authenticate their certificates(*.asc files) with cryptix.



Anyway, I believe you can do it. The web-app can do the authentication job,

but the container need information to do authorization checking.



======= The way to get credential info for web-app 
===========================

>>>A web application may well have a mixed user community,
>>>some authenticate by means of a password or other authenticators,
>>>others have a certificate for authentication.
> It essentially mandates one and only one mechanism for authenticating
> users per webapp. There are tricks you can play here but it gets quite
> complicated very quickly.

Yes. I checked again. It states "one of ....", unlike in JAAS, it can use a 
list.

But it is talking about the way how to get credential information.

Ralf & I are thinking about where to store users' information. I will talk 
this in next section.



I think that for a web-app, a web user might do not have a certificate.

then we should allow him to use username/password.

If we can config more than one login-config in order like JAAS, it will be 
better.



Would you please reconsider it? I think that it won't be too complicated.

When we find a resource is under constraint, we check the first 
login-config,

If it fails, we check the second one, ..



All the authenticators are doing the jobs.



====== Where to store user's information ==============

> The idea of checking multiple realms to authenticate a user should be
> a lot easier. I haven't looked at it but I would expect it to be
> relatively simple to implement a hybrid realm that contains an ordered
> list of realms and checks each of them in turn until the user is
> authenticated or it runs out of realms to authenticate against.

Your hybrid realm is almost the same idea of my term "UserContext".

The idea of multiple realms is what Ralf and I want.



Here, users with username/password might be stored in several places.

However, generally speaking, users with certificates will be stored in

 places different from places to store username/password.



>as is how that certificate is mapped to a user.

Great to see you are considering this.

However, it seems this sentence doesn't hit the point.

The map is between certificates & roles.
You mentioned:

> b) Realms map users to roles ...

When the user uses username/password, we map usernames to roles.

When the user uses certificates, we map certificates to roles.



>> For a specific web-app, all its users' certificate might be in a special 
>> place.

>>So some attribute of ssl connector should be attributes of UserContext.
> You need to be more specific. Which attributes?

scope=web-app|host|engine     whether users information available to other 
context. "host" is the default value.

useHost=yes|no    Using users defined in the host context. default: yes

useOtherWebApp=yes|no

    Using users defined in other web-app exposed to the same host. default: 
yes

useOtherHost=yes|no

    Using users defined in other host exposed to the same engine. default: 
no

clientAuth

keystoreFile

keystorePass

keystoreType

truststoreFile

truststorePass

truststoreType



The last 6 attributes of Connector element should become attributes of Users 
elements since they are all UserContext properties.



"clientAuth" is configed in the login-config element in web.xml. If the 
client is requesting a server resource that requires client authentication, 
the server requests the client's certificate. However, it could also be put 
on Users element to ask for client certificates for all resources in this 
web-app.



In one of msgs in this thread, i also give an example to config UserContext.



I also want a specific realm: a realm to deal with PGP certificates,

cryptix could be used.



=======UserManager Module================================

> Two clear reasons for what?

To add a usermanager module with usercontext component managing several user 
realms.

The whole thread is for adding a usermanager.



We can find many more reasons. I thought that you knew it for sure.

HttpServletRequest.getRemoteUser() should return the user name

when the user uses username & password.

or subject field of its certificate when the user uses a certificate.



HttpServletRequest.getUserPrincipal() should always return a web-app 
dependent Principal.

Rather than return something like org.apache.catalina.users.MemoryUser.

At present, the web-app use its own User object, and Catalina uses another 
user object for the same user.



Let web-app implement usercontext, although we should implement one for the 
engine,

And we can also implement a default one for all web-app. Anyway, it is the 
web-app's user,

 we just do some job to relieve web-app's burden.

 So web-apps should be encouraged to implement its own UserContext.

Web-apps will do more things on user object, not just authentication.



>> The realms in o.a.c.realm package mixed up authentication & 
>> authorization.

>>I suggest to separate them.
>>Authentication belongs to UserContext.
> The realm handles these processes together because they are tightly
> coupled. Separating them will add complexity.

>What is the justification for this?

Generally speaking, the design of authentication & authorization are 
interdependent.

However, when resources are authorized to roles,

 authorization is totally independent from authentication.

So the container can take care of authorization for web-apps completely.

In JAAS, authorization is done with java.security.AccessControlContext,
java.lang.SecurityManager, & java.security.ProtectionDomain.

Authentication is done with LoginModule & Callbackhandler.



The term "realm" in tomcat has a "wrong" definition. A Realm is a "database" 
of

usernames and passwords ., plus ..

The right definition is used by apache:

Areas of Controlled Access

In terms of voluntary control mechanisms on the Web, each protected area,

whether it be a single document or an entire server, is called a realm. When

a server challenges a client for credentials, it provides the name of the

realm so the client can figure out which credentials to send.



For authentication, web-app will have to access users' information anyway.

Let web-app do authentication is a good idea for at least 2 reasons:

1. Where & how to store users' information is web-app dependent.

2. We don't have to access database directly. Web-app might have cached user 
objects.



To assist web-app, we could implement some realms (has no function to do 
authorization)

To access database with jdbc, or ldap by get config from context.

And have all these realms managed by your "hybrid realms" (UserContext of 
web-app).

If you could just write an abstract class or an interface, and encourage 
web-app to implement it,

it will be better. all though one for the engine should be implemented by 
you.



One more thing, at present, we are using session based authentication.

A more secure solution is to use request based. When non-repudiation is 
required,

we should use request signature. A UserManager module with UserContext 
managing

several realms can be used by container & webapps.



I have been using tomcat for long time, and I haven't touched jboss.

But I will, I want to know how does jboss take care of all these things.


>Keep each proposal/patch focussed on a single issue.

The UserManager module will touch several issues. and with the same objects,

it will be easier to do management through admin tool.



>I would suggest that a detailed study of
> the authentication and authorisations sections of the servlet spec and
> the low-level workings of SSL would be good places to start your research.
I don't know much about ssl. I don't care much about it.

However, I have been spent much effort on authentication & authorization.



If i have some mistakes, i really appreciate it if you let me know.

thank you for reading my message.



jackzhp@hotmail.com






---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message