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
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 will
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
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_ decisions
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
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
-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 own private
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
:[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 included in JDK1.3
: [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 return a user principal at all, because
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 for the
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
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.
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
14 matches
Mail list logo