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/20 09:55:54 UTC
UserManager should be added
In order to add a new user to a web-app, since specification 2.4 doesn't
cover this, web-app might have to take care of this. User information will
be used by web-app anyway, the web-app keeps many information about the
user. Keep its password is not difficult at all, and it is easier for the
web-app to change password for the user. In case the user uses a
certificate, the web-app might also use the certificate anyway. So the
UserManager will be used by both the web-app Container & the web-app.
There are 3 types user contexts:
1. Engine user context (tomcat-userx.xml, should not mix up with host &
web-app user context. At present, they all mixed up.)
2. Host user context (Users defined in a host user context will be available
to all web-apps in this host.)
3. Web-app user context
Under the Engine element, add a Users element (EngineUserContext). Its
content is the content of tomcat-users.xml, and tomcat-users.xml could be
eliminate, or an attribute in Users link to tomcat-users.xml.
Under each Host element, there could be a Users element (HostUserContext),
too.
In the context.xml for each web-app, there could be a Users element
(WebAppUserContext), too.
In Host Users & web-app users elements, the possible attributes are:
scope=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.
Single Signon
At present, single signon is done with a valve.
For a user crosses a web-app (1) to another web-app (2) to access a
constrained resource, the authorizer(Realm) will call the UserManager
whether the user has a role for the resource. And the UserManager will
consult the user context of the web-app 2 to check whether it accept users
from web-app 1. If yes, and the user is authenticated, then the container
doesn't have to ask the user do authentication again.
This will be more logic than the original implementation with valve.
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
2 clear reasons
Posted by Jack <ja...@hotmail.com>.
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
The original Realm
Posted by Jack <ja...@hotmail.com>.
"Terry Zhou" <zh...@gmail.com> wrote in message
news:daa09eb00601200137k6e9fa75cr@mail.gmail.com...
>Tomcat does have a realm in different level(Engine,Host,Webapp) for
>security.
>Check http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html
Personally, I believe that the original Realm mixed up the authentication &
authorization.
It should be seperated into Authorizer & UserRealm.
The reason why I suggest to add user package is that the source code of the
original implementation is not easy to be integrated into the source code of
web-app.
Principal is web-app dependant
HttpServletRequest.getRemoreUser() returns the name of the user of the
request. When we use certificates, the return object is not well defined
since there is no name here.
HttpServletRequest.getUserPrincipal() doesn't have a good definition,
either. It just says the principal name of the current authenticated user.
So, what is in the returned Principal object is up to the container, too.
However, the reason to have such a method is to let the web-app can access
it. And so, the returned Principal should be web-app dependent. We had
better to ask the web-app to implement the Principal if the web-app care who
the user is. In such a case, we had better leave the authentication to the
web-app (in UserContext), too.
If the web-app doesn't care at all, then we can use GenericPrincipal as the
current implementation.
jackzhp@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
UserManager managing UserContexts
Posted by Jack <ja...@hotmail.com>.
"Terry Zhou" <zh...@gmail.com> wrote in message
news:daa09eb00601200137k6e9fa75cr@mail.gmail.com...
>Tomcat does have a realm in different level(Engine,Host,Webapp) for
>security.
>Check http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html
The document really says that, but as I tried, the result is disappointing.
It just doesn't work.
I guess the document might just give the direction to go. If it works for
you please let me know.
I added this into context.xml:
<Realm className="org.apache.catalina.realm.MemoryRealm"
pathname="conf/Catalina/localhost/dusers.xml">
</Realm>
Furthermore, I want to have a UserContext component. The users' information
might be store in several places.
Any classes just have to deal with UserContext, all details will be
encapsulated inside the UserContext such as access keystore, truststore, or
database, ldap.
And single signon will become more logic, easier to controle.
jackzhp@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
?realms in different level(Engine,Host,Webapp)?
Posted by Jack <ja...@hotmail.com>.
"Terry Zhou" <zh...@gmail.com> wrote in message
news:daa09eb00601200137k6e9fa75cr@mail.gmail.com...
>Tomcat does have a realm in different level(Engine,Host,Webapp)
> for security.
>Check http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html
Is there anybody using this? and it works?
I guess the developers just want to go that way.
I said it doesn't work in replying him, nobody give more information.
When i use this to replace the UserDatabaserealm, everything works well.
<Realm className="org.apache.catalina.realm.JDBCRealm"
driverName="com.sap.dbtech.jdbc.DriverSapDB"
connectionURL="jdbc:sapdb://192.168.1.98/tst?unicode=true"
connectionName="test" connectionPassword="test"
userTable="users" userNameCol="user_name"
userCredCol="user_pass"
userRoleTable="user_roles" roleNameCol="role_name" />
when i moved it to a web-app's context.xml, and the userdatabaserealm
enabled on engine level,
the one configued in context.xml doesn't work.
Furthermore, users defined in the engine level is available in the web-app.
Terry mentioned for security reason, i think that users defined in the
engine level should not be available to
the web-app. Yes, the users defined in engine level should not be available
to web-apps.
users defined in host level can be available to all its web-apps.
<Realm className="org.apache.catalina.realm.MemoryRealm"
pathname="conf/Catalina/localhost/dusers.xml">
</Realm>
in a specific web-app's context.xml doesn't work, either.
Thank you for reading this.
jackzhp@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: UserManager should be added
Posted by Terry Zhou <zh...@gmail.com>.
Tomcat does have a realm in different level(Engine,Host,Webapp) for
security.
Check http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html
2006/1/20, Jack <ja...@hotmail.com>:
>
>
> In order to add a new user to a web-app, since specification 2.4 doesn't
> cover this, web-app might have to take care of this. User information will
> be used by web-app anyway, the web-app keeps many information about the
> user. Keep its password is not difficult at all, and it is easier for the
> web-app to change password for the user. In case the user uses a
> certificate, the web-app might also use the certificate anyway. So the
> UserManager will be used by both the web-app Container & the web-app.
>
>
>
> There are 3 types user contexts:
>
> 1. Engine user context (tomcat-userx.xml, should not mix up with host &
> web-app user context. At present, they all mixed up.)
>
> 2. Host user context (Users defined in a host user context will be
> available
> to all web-apps in this host.)
>
> 3. Web-app user context
>
>
>
> Under the Engine element, add a Users element (EngineUserContext). Its
> content is the content of tomcat-users.xml, and tomcat-users.xml could be
> eliminate, or an attribute in Users link to tomcat-users.xml.
>
> Under each Host element, there could be a Users element (HostUserContext),
> too.
>
> In the context.xml for each web-app, there could be a Users element
> (WebAppUserContext), too.
>
>
>
> In Host Users & web-app users elements, the possible attributes are:
>
>
>
> scope=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.
>
>
>
> Single Signon
>
> At present, single signon is done with a valve.
>
>
>
> For a user crosses a web-app (1) to another web-app (2) to access a
> constrained resource, the authorizer(Realm) will call the UserManager
> whether the user has a role for the resource. And the UserManager will
> consult the user context of the web-app 2 to check whether it accept users
> from web-app 1. If yes, and the user is authenticated, then the container
> doesn't have to ask the user do authentication again.
>
>
>
> This will be more logic than the original implementation with valve.
>
>
> jackzhp@hotmail.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
----------------------------------------
Terry(Xiaochao) Zhou
an example of Users element
Posted by Jack <ja...@hotmail.com>.
Furthermore, the original Realm element could be moved into Users element.
The Users element should be able to include several Realm elements, such as
one for Database, another one for LDAP, even one more in tomcat-usrs.xml
format. Examples:
<Users keystoreFile="xxxxxx\.keystore" scope="web-app">
<Realm memory realm>
<user username="owner" password="jack" roles="owner"/>
<user username="xxx" password="jack" roles="aaa"/>
<user username="yyy" password="jack" roles="bbb"/>
</Realm>
<Realm memory realm src="users.xml" />
<Realm jdbc config/>
<Realm jndi config/>
<Realm ldap config/>
</Users>
The certificate of this web-app will be included in the context if it has
one.
When the web-app is running, it might have to access its own certificate,
too.
jackzhp@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Thank you for response
Posted by Jack <ja...@hotmail.com>.
"Bill Barker" <wb...@wilshire.com> wrote in message
news:dr1hkt$vkf$1@sea.gmane.org...
> Really a users@ question, so I won't bother to reply inline.
It's my pleasure to have your response.
> What Jack wants is pretty much an enhanced version of UserDatabase. He
> can do much of what he wants with a really fancy custom UserDatabase, but
> would need changes to do more advanced X509 stuff (also, the current
> config wouldn't be as nice as he would want).
You are pretty right.
Since the design of authorization in the spec allows authorization to be
speparated from authentication.
The container is able to take care of all authorization checking.
However, authentication is more web-app dependent. Authentication doesn't
mean we have to use ssl,
as I have mentioned in "a bit info".
It seems that you agreed to the solution in reply to my post "Realms in
tomcat" in user group.
Any idea to implement such a fancy UserDatabase?
I hope Mr. Thomas' hybrid realms could deal all the following
"medias"/"realms"
All the following things at the same level, they all should be managed by
his "hybrid realm" (UserContext)
access database through jdbc for username/password & roles
access database through ldap for username/password & roles
access xml file for username/password & roles
access xml file for certificateid/keyid/email & roles map
access database for certificateid/keyid/email & roles map
access online PGP keyserver
access local keystore
access local cacerts
Such a hybrid realm/UserContext of a web-app should be hybrid.
Every web-app has a usercontext, the engine has a usercontext, and every
host has a usercontext.
The roles are defined in web.xml. For engine usercontext, its roles are
defined in tomcat-users.xml
One application:
PGP keys are stored on online keyserver, however,
the map between roles & keyid/email/certificateid could be stored on local
xml file or database.
Any idea on how to put all these things in a UserDatabase?
I have tried to do UserManager, UserContext managing all kinds of realms,
and separate all these things from the original realm package
(leave the original realm package continue act as a authorization checker).
Later, I found that if my code can not be integrated into tomcat, when
tomcat evolves
my source code will have to be changed all the time, then I gave up.
Instead, I have to deliver my idea to you guys.
Thanks!
jackzhp@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Mr. Thomas please check this.
Posted by Bill Barker <wb...@wilshire.com>.
Really a users@ question, so I won't bother to reply inline.
What Jack wants is pretty much an enhanced version of UserDatabase. He can
do much of what he wants with a really fancy custom UserDatabase, but would
need changes to do more advanced X509 stuff (also, the current config
wouldn't be as nice as he would want).
"Mark Thomas" <ma...@apache.org> wrote in message
news:43D41228.3040807@apache.org...
> Jack wrote:
>> 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.
>
>>>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.
> The servlet spec gets in the way of some of your ideas here. 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.
>
>> I have the same opinion. That's why I suggest to use UserContext for each
>> web-app.
> 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.
>
>> 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? Greater control
> per-realm of how a client certificate is verified is certainly
> possible, as is how that certificate is mapped to a user.
>
>> The realms in o.a.c.realm package mixed up authentication &
>> authorization. I
>> suggest to seperate 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?
>
>> I hope my information can be a little bit helpful to you.
>> jackzhp@hotmail.com
> Some of your ideas have potential but others are clear non-starters.
> To make your information more useful I would suggest some detailed
> research followed by the development of one or more concrete
> proposals, preferably supported by patches. Keep each proposal/patch
> focussed on a single issue. 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.
>
> Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Mr. Thomas please check this.
Posted by Mark Thomas <ma...@apache.org>.
Jack wrote:
> 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.
>>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.
The servlet spec gets in the way of some of your ideas here. 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.
> I have the same opinion. That's why I suggest to use UserContext for each
> web-app.
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.
> 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? Greater control
per-realm of how a client certificate is verified is certainly
possible, as is how that certificate is mapped to a user.
> The realms in o.a.c.realm package mixed up authentication & authorization. I
> suggest to seperate 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?
> I hope my information can be a little bit helpful to you.
> jackzhp@hotmail.com
Some of your ideas have potential but others are clear non-starters.
To make your information more useful I would suggest some detailed
research followed by the development of one or more concrete
proposals, preferably supported by patches. Keep each proposal/patch
focussed on a single issue. 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Mr. Thomas please check this.
Posted by Jack <ja...@hotmail.com>.
Hi,
Mr. Thomas,
I know you are doing this.
On January 20, 2006, under
http://issues.apache.org/bugzilla/show_bug.cgi?id=7831,
you mentioned:
>I'm happy to look at adding CLIENT-CERT support to the JNDI realm
> based on your (Mario Ivankovits) proposal. If I put together a patch are
> you willing to test it?
When we use client-cert, we might be not using ssl at all since we don't ask
confidential transfer.
Ralf Hauser report the bug:
http://issues.apache.org/bugzilla/show_bug.cgi?id=34643
He mentioned this:
>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.
I have the same opinion. That's why I suggest to use UserContext for each
web-app.
A UserContext can contains several realms since a realm only handle one
database or directory service.
Any kind of user with certificate or username/password, a web-app dependent
UserContext can always do the authentication.
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.
The realms in o.a.c.realm package mixed up authentication & authorization. I
suggest to seperate them.
authentication belongs to UserContext.
I hope my information can be a little bit helpful to you.
jackzhp@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Please give me some responses!!
Posted by Mark Thomas <ma...@apache.org>.
Jack wrote:
> Hi,
>
> guys, please give me some responses!
Intended for the users list but just as applicable here:
http://tomcat.apache.org/faq/tomcatuser.html#why
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Please give me some responses!!
Posted by Jack <ja...@hotmail.com>.
Hi,
guys, please give me some responses!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org