This topic has not yet been written. The content below is from the topic description.
The JavaEE specifications typically mandate container based authorization which tend to be coarse grained. For Web Applications, there is enforcement on web resources (via URLs) using roles. The beauty of container based security is that user applications can delegate authentication, authorization and auditing to the container. But coarse grained authorization may not solve all user applications' access control needs. You may have some fine grained use cases or context based use cases such as the following: "Allow access to this part of the web applications for users who are 18 years and older" "Only managers can update the payroll of their subordinates" "Allow access to this section of the web application to users who are employed, accessing from the US, between 9am-5pm on Monday-Thursday" These cannot be catered to by the access control mechanism in the Servlet specification, for example. You can turn off container security and try to do this yourself via servlet filters. What is the problem in doing this? Each time the requirements change, you have a code change. How nice will it be if you could externalize the policy infrastructure from your code? JACC does do it with PolicyConfiguration etc. But it is not as extensive as Oasis XACML specification. The great thing about Oasis XACML specification is that it is totally tailored towards access control and IT DOES NOTHING ELSE. It defines a language and structures to define your policies/rules and an architecture for a decision point (aka Policy Decision Point, PDP) and one or more Policy Enforcement Points (PEPs).