tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arkin <ar...@exoffice.com>
Subject Re: authorization providers (was More on JAAS)
Date Wed, 19 Apr 2000 20:44:51 GMT
> This still requires a callback somewhere to populate the roles. (or
> does it? I thought perhaps SecurityCheck could call isUserInRole
> and if true add the role to the request, if not, remove or don't add
> the role)


My understanding, the role list should be available form some interface
(let's call it RolesCredential for now) and the container can call
isInRole() any number of times in any order. That defines that the role
list is always "loaded" from the container's perspective.

An implementation may load all roles at once when constructing a
RolesCredential, or it may load them lazily (e.g. by keeping an open
connection to the LDAP server), or it may otherwise obtain them (e.g.
from an independent role-enlistment cache).

The callback is not the responsibility of the container or the
interceptor, it's the responsiblity of the authorization module that
returns a RolesCredential.

BTW the following is unspecified, but is desired behavior. The roles to
which a user belongs are determined when the authentication happens,
once authenticated the list of roles will never change even if roles are
lazily loaded. Any deviation from that can cause conflicts when the
application consists of other mechanisms (EJB, connectors, Kerberos)
that might depend on roles.

arkin



> >
> > What model for request processing do you prefer ?
> >
> > My personal preference is to use Event and EventListeners -
> > they have a simpler design and resolve the same problem.
> > Maybe one day I'll just implement that as a revolution,
> > with a lot more care for GC.
> > But I'm not sure it is "better" - and I'll not be sure until
> > I have a prototype and I can compare it and see how it works
> > in real world.
> 
> Actually that's what I've been thinking as well. That perhaps we
> have an AuthenticateEvent and AuthorizationEvent. I'm still thinking
> on what would make this up (e.g. what gets passed to what).
> 
> Though I think you need the events to be a two-way street.
> 
> >
> > Web servers have a long history and a lot of smart developers,
> > and this model seems to work - and it was more than used in
> > all those years. I need more than words to use something
> > out of whiteboards.
> I agree completely. That's why I think perhaps for 3.x we should
> just get something to work. We're already pretty close in terms
> that we can replace the SecurityInterceptor with something and
> authenticate & even authorize a user with a userid & password.
> 
> If we can figure the quickest way to get roles popluated, then I
> think we'll be rather set. I'd be happy to add in the callbacks if
> someone can at least tell me where I need to put in the hooks.
> 
> Then for 4 we can get something better in place. This is sort of like
> Apache. 1.3.x was make it work. 2.0 is how to make it work now
> knowing what we know.
> 
> All of this stuff is just so new, I don't think we know enough really
> to say yea or ney on much of anything (in particular since we've
> only dealt with the theoretical so far ;).
> 
> I'd also be happy to tackle the event issue, though that's going to
> be a while (most likely) since that's not an area I'm real familiar
> with and I'm committed to several projects in May (though after
> May, I'm pretty free).
> >
> 
> > > So while I agree Tomcat will/shouldn't replace the everyday
> > > workhorse Web servers, there are areas where it likely will fill in
> > > where we cannot see (if you can, make sure you have access to
> > > some VC because you'll likely cash in big).
> >
> > If we expect people to use servlets/jsp instead or in addition to
> > mod_perl/php/asp we should be able to run in similar conditions
> > with similar speed. If the response time is more than 2 seconds -
> > nobody cares that your software can also run from a toaster. If you can't
> > use the same authentication as the rest of your applications -
> > nobody cares that you have plugeable  APIs or original architecture.
> Yes, I just had to wait several seconds for my JSP to compile and
> connect to my local LDAP server on my NT box at home. After the
> initial compilation it was quick, but until then...
> 
> Though I wonder if perhaps this is an issue that can be taken care
> of smarter caching or configuration. For example if I don't change
> my JSPs between startups, why should the servlet engine
> recompile it? Couldn't we just make a hash of the JSP and store it
> first and then check to see if it's changed between startups before
> we recompile. And if it hasn't can't we just reload the servlet we've
> recompiled (if we're already doing this, please accept my humble
> apoligies).
> >
> > If we discuss about how the request is processed - including authentication -
> > I'm interested to hear how much processing is part of the critical path,
> > how and what alghoritms and data structures can we use to implement
> > the parsing and searching, and how can we reuse existing code.
> >
> I agree. I think that we're concentrating so much on particular
> issues we're missing the bigger picture (e.g. missing the forest for
> the trees).
> 
> 
> 
> > If we discuss about authentication - I'm interested how can we address
> > existing systems ( like apache + any auth module). In a controled
> > environment everything works fine and looks flexible.
> >
> I think we handle communication with the Web server via the
> protocol.
> 
> Which also brings up the question, do we continue to use our
> current protocol or a different one. For example does it need to be
> TCP based or could it be UDP? Or do we investigate something
> like CORBA or even Mozilla's XPCOM (not Mozilla itself just the
> XPCOM protocol).
> 
> BTW Is it ok to post code samples here as zips or should I put
> them on the net somewhere for someone to pick up and place in
> CVS?
> 
> Mark
> > Costin
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

-- 
----------------------------------------------------------------------
Assaf Arkin                                           www.exoffice.com
CTO, Exoffice Technologies, Inc.                        www.exolab.org

Mime
View raw message