that is JBoss 4.0.3 SP1 not SP3
Why should the Jacc provider be called if your web resources are not secured? Unnecessary security overhead is always loathed.
The JBoss behavior is consistent.
My understanding is that the security contraints in a deployment descriptor are the standard declarative model for java policy. I want to replace that policy with a completely different kind of policy.
It seems odd that I have to explicitly allow all access in the descriptor just so I can dissallow it later with my own policy. I do not have to do this in WebSphere (Not that WebSphere is the model for all app servers!)
What is happening I would call an optimization that should be turned off when a different JACC implementation is registered.
Your explanation does not make sense to me. Can you elaborate as to what you are trying to achieve?
I noticed in other posts that you(Anil) are looking into, or already created, an XACML JACC provider. I'm doing something similar.
Suppose I have an XACML policy that specifies "/index.jsp" as the protected resource(target). I have no need for the security contraints in the deployment descriptor. I won't enforce them as I only enforce the XACML policies. But, when someone brings up index.jsp, and no security constraint exists in the deployment decriptor, the JACC provider doesn't even get called. I'm not able to even evaluate the policy to grant or deny access.
To work around this I place a security contraint on all web resources that allows all access. Then JBoss calls JACC on all web accesses and I'm able to evaluate the XACML policy and grant or deny access.
WebSphere will call the JACC provider regardless of the security contraints in the deployment descriptor. This is the behavior I expected from JBoss.
I have no intention of mixing XACML and JACC together ever.
For your usecase/needs, a custom tomcat valve is all you need. In the valve, do whatever you want. You can emulate whatever you claim is Websphere's behavior. ;)
The valve will be called irrespective of any security settings in the web.xml
As to XACML in JACC I was referring to these entries: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=66840
Yes I could implement this with a tomcat valve, and U looked at it - but my then my code would not work for WebSphere/WebLogic/... (I haven't checked to see how webLogic behaves yet) JACC is the standard to implement this.
I still say that this is a bug.
I browsed the defect list and found this has already be entered as a defect: http://jira.jboss.com/jira/browse/JBAS-2519
It also indicates some differing of opinion as to whether it is a defect or an enhancement.
JACC is not a complete delegation of all policy to an external provider. Its a mechanism for externalization the authorization decision when the container decides this is needed based on the web.xml/ejb-jar.xml security constraints. JBAS-2519 should be a feature request to delegate all authorization decisions. This has to be reconciled with the behavior of the request caller identity methods which have historically simply returned null for unsecured resources.
I still do not understand how we can get this feature request of delegating all authorization decisions(of course based on some configuration) including those for unsecured resources to a JACC policy provider.
The issue is simple: if there are no Security Constraints defined in the web app, no tomcat authenticators are installed for the web app. If there are no authenticators, then the question of realm does not arise.
If you secure part of your web app with security constraints, then an authenticator gets installed. In that case, we will be able to delegate to a jacc provider even for the set of resources that are not secured. I need to test this though.
But if we want configuration that will allow requests to pass thru a realm->JACC provider even when the web app is totally void of constraints, then I do not know how to do this.
Is my understanding right or am I assuming something wrong?
Its essentially a request to allow for a configuration where all requests can be intercepted by a jacc authorization decision. This is not a standalone issue since authorization is meaningless without a preceeding authentication providing an identity to authorize. There has to be some security related config to enable delegation. There can be meangingful authorization enhancements even for unauthenticated requests, so lack of authentication should not preclude an authorization check when configured to delegate all such checks.
The modifications suggested by Steve in the JBAS-2519 issue for the JaccAuthorizationRealm would be a good starting point.
I have two usecases for a webapp:
a) The web.xml defines zero security constraints, implying the webapp is totally insecure.
b) The web.xml secures a portion of the webapp. There is a subset of the webapp that represents unsecured resources.
In case a), there is little we can do. No identity(authentication) is established and jacc delegation for authorization is meaningless.
In case b), I am guessing that a jacc delegation for both the secure and unsecured resources should be possible (from a perspective of current tomcat/jboss implementation) to delegate to a jacc provider (via some config asking for delegation for unsecured resources).
A boundary case is:
c) Identity of the user is established by some other means - sso, federation etc. If the webapp is totally insecure (zero security constraints), should we delegate to jacc (now that the identity of the caller has been established and the jacc provider may need to authorize, irrespective of whether the web.xml defines security constraints)???
Is my understanding right?
I have tested that the jacc delegation can be performed for unsecured resources, if security constraints are installed for a subset of the resources in the web-app. The security constraints can be for a set of resources that do not even exist in the web application (like /restricted/* or /unrestricted/*)
Also, the SecurityConstraints can be installed via a "findSecurityConstraints" method in the external Jacc policy provider or a SecurityConstraintProviderClass that can be installed in the JACCAuthorizationRealm as shown below:
<Realm className="org.jboss.web.tomcat.security.JaccAuthorizationRealm" unprotectedResourceDelegation="true" securityConstraintProviderClass="org.jboss.test.security.test.CustomSecurityConstraintProvider" certificatePrincipal="org.jboss.security.auth.certs.SubjectDNMapping" />
Thanks for looking at this! It sounds like I'm expecting all three use cases.
For use case A. Even if no authentication has occured, I'd still like to enforce restrictions based on time and IP address: "home.jsp can only be accessed between 8AM and 5PM from this subnet..."
For use case C we are doing SSO but I think we will be OK since we use a custom JAAS login method.
Thanks - Cameron Morris