Jeanfrancois Arcand wrote:
>>If we look at JSR115, it sugests creating several (3?) permission objects
>>- each will be associated with the request.
>>
>>The creation of those objects will be part of the container ( probably in
>>a valve or other module ).
>>
>>The point is that all _authorization
Costin Manolache wrote:
Jeanfrancois Arcand wrote:
Where the permission object will be created? In Authenticator? I would
prefer delegating the permission to Authorization interface (but I can
live it :-) ). There is also another problem. If the permission is not
granted, the method will re
Jeanfrancois Arcand wrote:
> Where the permission object will be created? In Authenticator? I would
> prefer delegating the permission to Authorization interface (but I can
> live it :-) ). There is also another problem. If the permission is not
> granted, the method will return false. Then we wil
Costin Manolache wrote:
What about this:
instead of 3 methods, have a single method:
interface Authorization {
boolean hasPermission( HttpServletRequest, Permission perm )
}
115, not 155 :-)
Where the permission object will be created? In Authenticator? I would
prefer delegating the perm
What about this:
instead of 3 methods, have a single method:
interface Authorization {
boolean hasPermission( HttpServletRequest, Permission perm )
}
I'm still trying to figure out the hack in JSR155 ( with the
permission per request ) - but if you understand it we can even
use
boolean i
It seems I missread your post, I tought you would add another
authentication interface too ...
But I still don't like the interface :-)
I need to think about it.
I'm pretty sure we can use Policy, Permission, etc without a security
manager, and it would be better to go directly to use those.
On
Costin Manolache wrote:
Jeanfrancois Arcand wrote:
Costin Manolache wrote:
Wouldn't be better to just standardize on JAAS for authentication
and stop using our own private interfaces ?
AFAIK JAAS is included in JDK1.3+ - and available to older VMs.
I agree on JAAS too for Auth
Jeanfrancois Arcand wrote:
> Costin Manolache wrote:
>
>>Wouldn't be better to just standardize on JAAS for authentication
>>and stop using our own private interfaces ?
>>AFAIK JAAS is included in JDK1.3+ - and available to older VMs.
>>
> I agree on JAAS too for Authentication if it is available
List
Subject: Re: [5.0] Splitting authentication and authorization.
Filip Hanik wrote:
>In JBoss they have the following problem with JAAS.
>You protect /myapp/secure, the user logs on. When the user is in another subcontext,
>for example,
>/myapp/nonsecure/ JAAS doesn't retur
in Manolache [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 28, 2003 10:18 AM
To: [EMAIL PROTECTED]
Subject: Re: [5.0] Splitting authentication and authorization.
Wouldn't be better to just standardize on JAAS for authentication
and stop using our own private interfaces ?
AFAIK JAAS is
Costin Manolache wrote:
Wouldn't be better to just standardize on JAAS for authentication
and stop using our own private interfaces ?
AFAIK JAAS is included in JDK1.3+ - and available to older VMs.
I agree on JAAS too for Authentication if it is available for the
majority of open source VM
Filip
-Original Message-
From: Costin Manolache [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 28, 2003 10:18 AM
To: [EMAIL PROTECTED]
Subject: Re: [5.0] Splitting authentication and authorization.
Wouldn't be better to just standardize on JAAS for authentication
and stop using our o
Wouldn't be better to just standardize on JAAS for authentication
and stop using our own private interfaces ?
AFAIK JAAS is included in JDK1.3+ - and available to older VMs.
The only problem is getUserRoles(), which is not supported very well
by JAAS.
I'm fine with implementing them as valves
Hi,
since the last time I've proposed to split
Authentication/Authorization, we have moved to JMX Listerner as hooks
and standardize on JMX, I would like to re-open the discussion on
splitting the behaviour. Mainly, I would like to move three Realm
methods into an Authorizer interface and use
14 matches
Mail list logo
