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 will be deletated to >>a plugin - tomcat will just make the calls. It will be tomcat's >>job to provide the arguments and deal with the response. >> > OK. But I would prefer nmot having that code in the current > AuthenticatorBase. We will need something inbetween AuthenticatorBase > and AuthorizationBase (WebPermissionUtil)
As long as authorization (and authentication) does not deal directly with http requests ( i.e. plain JSR115/Java security + JAAS ) - I'm fine. Separating the authorization and authentication abstractions is one thing - implementing the request processing is another. WebPermissionUtil needs to know how to do the calls to authorization/authentication and how to provide the right permissions. I don't see too much value in having AuthenticatorBase and AuthorizatiorBase - if the authorizer is a ProtectionDomain or Policy, all we need is an implementation of that, called from the a valve. >>I don't think mixing HTTP request processing in the authorizer is a good >>idea, and it seems JSR115 ( at least the published draft ) is on the same >>side. >> > Well, I agree...if we have something in between Authentication and > Authorization :-) That's the current valve - with the authorization code moved in a TomcatProtectionDomain class ( that extends ProtectionDomain, is pluggable, etc ) I would make the JAAS valve the default - and hope that Nacho and the other people will be able to refactor the LDAP/JDBC valves to JAAS plugin modules ( bonus: they'll become reusable in other servers that use JAAS ). >>Another reason to let the authorizer deal with authorization and nothing >>else. A false will mean "FORBIDDEN". ( we can still know what was >>forbidden - we'll have to check 3 different permissions )\ >> > True. Using the permission type we can find the which error type to > return. Or what action to perform - redirect to the login page, etc. >>It seems JSR115 is a bit confused about this - in 4.7 it lists 6 >>alternatives for checking. I don't see why anything more than providing a >>PermissionCollection and using impies() would be needed. >> >>But I'm fine with ProtectionDomain - it adds the CodeSource of the >>context ( which is good ). Not sure what the principals would be. >> > The small problem I see is if we go with a PermissionCollection, people > interested in extending the model will be limited by the > PermissionCollection design. I would prefer having an implementation of > a Policy object instead. The problem with Policy: " There is only one Policy object in effect at any given time " ( in javadoc). That limits a lot our flexibility. Having a PermissionCollection per server or per Context still permits people to have them in the global Policy. Each Context will be associated with a CodeSource ( it is already AFAIK ), and the Policy is just a container for CodeSource->PermissionCollection. If we use PermissionCollection in our code, it is very easy to extract it from a Policy ( if one is present ), but we can have more flexibility. It would be possible to plug in a PermissionCollection in a context - without having it in the Policy, and we can use tomcat with a "foreign" policy, installed by a different application ( which may not support 115 ) >>>Here is how I see the process (simplified): >>> >>>(1) when Tomcat starts, create the Policy (Provider is we standardize on >>>115) >>> >>> >> >>There is no requirement on that - we can create a ProtectionDomain or >>Policy without 115. ( well, we already do - AFAIK - for the class loader >>). >> > Here I mean the Policy implementation. See my previous comment. I'm ok with having a Policy created - but as an optional step, our code should use PermCollection. If a Policy already exists - and it can be used ( i.e. 115 compatible ) - we should use it, but it shouldn't be required. ( by JSR115 compatible I mean it support the interfaces that allow us to modify it ) >>>(2) when deploying web.xml, created the appropriate Permission object >>>(proprietary or 115) and store them inside a PolicyConfiguration object. >>> >>> >> >>That's my biggest problem with 115 :-) >> >>All J2EE is moving toward JMX - and they define yet another config API. >>Sorry - I will vote for proprietary here ( actually - JMX ). The Policy >>will just be an MBean ( of cource, that assummes JMX1.2 - so the mbean >>server is protected ). >> > There is nothing that prevent us implementing a PolicyConfiguration > using JMX and still be 115 compliant. Doing that will allow changing the > permission without stopping the container. That's a very nice feature. I know - my point was that JSR115 should specify the JMX attributes and mechanism - instead of defining the interfaces. Look at JSR77 for example ( which is far from perfect, but IMO goes in a very good direction ). >>Even if some base implementation in java are dependent on the >>SecurityManager - we'll likely use our own Permission and Policy and >>ProtectionDomain implementation, and that doesn't have to depend on SM. >> > Just fine. > > To summarize (trying to port my UML view using text :-) ), here is the > way it will work: > > At Startup: > - create the TomcatPolicyImpl If one is not present - if tomcat is embeded in a J2EE server, most likely one will be. Or we just ignore the javadoc spec for Policy - which requires a single Policy in effect. > Deployment > - generate all the permission > - add them inside a JMXPolicyConfiguration as a PolicyCollection, associated with the context > - add the JMXPolicyConfiguration to TomcatPolicyImpl or add the PolicyCollection to the Context, and use the notifications to inform the policy mapper. > Runtime > - AuthenticatorBase: create the permission (here I wull recommend the > delagation of the task to a WebPermissionUtil object) > - AuthenticatorBase: call Authorization (which is TomcatPolicyImpl) I don't like mixing the Authenticator with request processing either :-) Let's call it SecurityValve - which will call the Authenticator for authentication and Policy for authorization. About Authenticator interface - that's either the current Realm ( with authorization methods deprecated ), or we standardize on JAAS and refactor the existing realms and user database to generic ( tomcat independent !) JAAS plugins. > Looks simple :-) What do you think? I like it - I think it cleans a lot of things. Costin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
