Glenn Nielsen wrote:
> There are a number of different types of realm implementations in
> org.apache.catalina.realm. These are all solely used for web application
> realm based authentication except for those which implement the
> UserDatabase which understands users, groups, and roles and has me
Sorry to be late commenting on this. I have been busy with non Tomcat stuff. I have
read most of the thread and just picked the original proposal to reply to.
I agree that authentication and authorization should be split out into separate
interfaces.
I also think it would be nice if the web ser
Jeanfrancois Arcand wrote:
>>I would very much preffer a consistent mechanism for all the hooks in
>>tomcat. In 3.3 there is one interface ( BaseInterceptor ) where all
>>the possible hooks are defined ( with a number of problems we already
>>know regarding ordering, but that's a different issue )
Costin Manolache wrote:
Jeanfrancois Arcand wrote:
Why would someone use this instead of web.xml ?
Because you can start using the java.security.Provider.checkPermission
for granting/denying resources.
Not sure this would be the most efficient solution - the mapper is
( or wi
Costin Manolache wrote:
Remy Maucherat wrote:
I'll only be talking about HTTP authentication and the interaction with
the realms for now.
The main problem is that some authentication schemes need the realm to
function (digest, for example). So I don't see how we can put that layer
of processin
Remy Maucherat wrote:
> I'll only be talking about HTTP authentication and the interaction with
> the realms for now.
>
> The main problem is that some authentication schemes need the realm to
> function (digest, for example). So I don't see how we can put that layer
> of processing in Coyote, si
Costin Manolache wrote:
Jeanfrancois Arcand wrote:
Sorry, I missed the first part of the discussion.
Why would someone use this instead of web.xml ?
Because you can start using the java.security.Provider.checkPermission
for granting/denying resources.
Not sure this would be the most effi
Jeanfrancois Arcand wrote:
>>Why would someone use this instead of web.xml ?
>>
> Because you can start using the java.security.Provider.checkPermission
> for granting/denying resources.
Not sure this would be the most efficient solution - the mapper is
( or will be ) optimized on the way it is
Costin Manolache wrote:
Jeanfrancois Arcand wrote:
Costin Manolache wrote:
IMO - I would rather see us using JAAS directly as API
instead of defining our own.
Can you elaborate a little more? JAAS will certainly help for user/group
authentication/authorization, but I don't th
Jeanfrancois Arcand wrote:
>
>
> Costin Manolache wrote:
>
>>IMO - I would rather see us using JAAS directly as API
>>instead of defining our own.
>>
> Can you elaborate a little more? JAAS will certainly help for user/group
> authentication/authorization, but I don't think you can use it for
Costin Manolache wrote:
IMO - I would rather see us using JAAS directly as API
instead of defining our own.
Can you elaborate a little more? JAAS will certainly help for user/group
authentication/authorization, but I don't think you can use it for
granting/denying web resources (JSR 115 is
IMO - I would rather see us using JAAS directly as API
instead of defining our own.
I already mentioned that I would preffer using JNDI for
abstracting the informations about user/group. In general, the
fewer interfaces we define, the better it is.
Costin
Jeanfrancois Arcand wrote:
> Hi,
>
>
On Wed, 27 Nov 2002, Jeanfrancois Arcand wrote:
> I would like to create a new interface called Authorizator(and a default
> AuthorizatorBase) that will take care of those methods.
I'd be a lot more willing to buy in to Authorizer and AuthorizerBase :-).
The initial Realm design definitely com
Hi,
I would like to propose the following re-factorisation of the current
Realm interface. Righ now, Realm contains 3 methods related to
authorization:
hasRole
hasUserDataPermission
hasResourcePermission
I would like to create a new interface called Authorizator(and a default
AuthorizatorBase
14 matches
Mail list logo
