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/21 05:57:25 UTC
Please give me some responses!!
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
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