You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jack <ja...@hotmail.com> on 2006/01/22 20:32:35 UTC
2 clear reasons
1. The Users of a web-app might be defined in several places such as
Database, or a file.
2. when we are not using ssl, but ask for client certificate.
We have to map certificats to roles. Although most certificates can be
mapped to a generic role.
A few certificates might be mapped to some specific roles.
jackzhp@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 2 clear reasons
Posted by Leon Rosenberg <ro...@googlemail.com>.
Yeah Jack,
it would be great if you would reply to the existing threads instead
of starting new ones with each message.
tia
leon
On 1/22/06, Mark Thomas <ma...@apache.org> wrote:
> Two clear reasons for what?
>
> Mark
>
> Jack wrote:
> > 1. The Users of a web-app might be defined in several places such as
> > Database, or a file.
> >
> > 2. when we are not using ssl, but ask for client certificate.
> > We have to map certificats to roles. Although most certificates can be
> > mapped to a generic role.
> > A few certificates might be mapped to some specific roles.
> a) You can not use ssl and ask for client certificates. CLIENT-CERT
> requires the use of ssl.
> b) Realms map users to roles regardless of authentication mechanism
> (BASIC, DIGEST, FORM or CLIENT-CERT). There are a few gaps in the JNDI
> realm implementation and I am working on these at the moment as a
> result of bug 7831.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
a bit info
Posted by Jack <ja...@hotmail.com>.
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" <ma...@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
Re: 2 clear reasons
Posted by Mark Thomas <ma...@apache.org>.
Mark Thomas wrote:
> a) You can not use ssl and ask for client certificates. CLIENT-CERT
> requires the use of ssl.
Sorry typo. This should read "You can't not use ssl and..."
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 2 clear reasons
Posted by Mark Thomas <ma...@apache.org>.
Two clear reasons for what?
Mark
Jack wrote:
> 1. The Users of a web-app might be defined in several places such as
> Database, or a file.
>
> 2. when we are not using ssl, but ask for client certificate.
> We have to map certificats to roles. Although most certificates can be
> mapped to a generic role.
> A few certificates might be mapped to some specific roles.
a) You can not use ssl and ask for client certificates. CLIENT-CERT
requires the use of ssl.
b) Realms map users to roles regardless of authentication mechanism
(BASIC, DIGEST, FORM or CLIENT-CERT). There are a few gaps in the JNDI
realm implementation and I am working on these at the moment as a
result of bug 7831.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org