PicketBox XACML v2.0.9.Final Released

PicketBox XACML v2.0.9.Final has been released.

You can download it from http://www.jboss.org/picketbox/downloads

Information available at https://community.jboss.org/wiki/PicketBoxXACMLJBossXACML

Mostly a bug fix release. Except that we have made the PDP evaluation configurable with locks.

Release Notes - PicketBox - Version picketbox_xacml_2.0.9.Final

Bug

• [SECURITY-738] - XACML DatabaseResourceAttributeLocator fails when used with Oracle 11g Driver
• [SECURITY-742] - JBossPDP.evaluate() lock should be flexible

Enhancement

• [SECURITY-734] - Slow policy evaluation with a large number of policy sets

Release

• [SECURITY-743] - Release PicketBox XACML 2.0.9.Final

Authorization (Access Control) Best Practices

After the recent wrestling match in the blogosphere that included vendors and analysts on XACML, I want to provide some best practices for access control/authorization.

The wrestling match is covered in my earlier post.

Let me insert my favorite punch line before I mention the best practices.

Authentication is finite while Authorization is infinite.


Best practices for access control:

1. Know that you will need access control/authorization.

Too many times architects spend majority of their system security design time on authentication and federated identity. This leads to limited time provided to authorization. Compared to authentication, authorization can get very complex over time. 

2. Externalize the access control policy processing

You are headed toward disaster if your access control processing is embedded in your application. This is because access control requirements are never complete during the first phase of application development. Authorization rules or requirements change over the application lifecycle as business needs or environment change.  If the access control processing is not decoupled from the application, you will face hardship. Lots of band-aid will be applied to the application code to meet the changing/ever-growing authorization requirements.

3. Understand the difference between coarse grained and fine grained authorization

Google/Bing will help you understand the difference. Wikipedia will definitely help you here. Application designers tend to create a model of authorization (for simplicity) during initial design. Almost always, this model tends to be a simple coarse grained authorization model. The challenge is that the read world authorization needs for your application is not set in stone. It is an ever changing phenomenon that will just pull your model in all directions.

4. Design for coarse grained authorization but keep the design flexible for fine grained authorization

This goes in line with item 2 where the access control policy has to be separated or decoupled from your application.  If your initial design for the access control system or library is designed for coarse grained authorization, because of the low coupling, it becomes easier to incorporate fine grained authorization logic over time.

5. Know the difference between Access Control Lists and Access Control standards

Access Control Lists (ACL) are pretty popular among system designers. The challenge is that they are proprietary and not usable across applications or domains. You may earn your bonus or accolades using ACLs in your application. Over time, they tend to become restrictive due to changing requirements.

There are 2 prominent access control standards that I list here:

a) IETF OAuth2: this is a REST style Internet Scale lightweight resource authorization framework.

b) OASIS XACML: standard for fine grained authorization. Has an access control architecture namely PEP (Policy Enforcement Point), PDP (Policy Decision Point), PIP (Policy Information Point) and PAP (Policy Administration Point).

Fig: Typical XACML Fine Grained Access Control Architecture

6. Adopt Rule Based Access Control : view Access Control as Rules and Attributes

Access Control should be viewed as rules on various entities (and their attributes) involved in the authorization check.

I am not forcing you to use XACML.  But I would certainly encourage you to design your access control system in terms of rules and attributes.  Have a look at my article on Access Control Strategies. It is critical that you design your access control system as rules and attributes.

Hey, Drools based access control system is certainly not bad as long as you decouple the access control system. It is a trade off between proprietary rigid ACLs and flexible fine grained XACML. You can manage your Drools Rules via Guvnor.

7. Adopt REST Style Architecture when your situation demands scale and thus REST authorization standards 

With the growing demand for web based services and APIs and the proliferation of mobile devices in the world, it has become essential to incorporate REST style architecture to your system design.

It is essential for you to use OAuth2 standard for REST authorization. While OAuth2 takes care of defining the tokens and some rules for authorization (scope of authorization and actor/resource), it may still be essential for system architects to incorporate fine grained authorization.  Certainly give a look at the REST Profile of XACML v3. There is also JSON binding available.

8. Understand the difference between Enforcement versus Entitlement model

Prominent access control strategies and standards involve the Enforcement model. The access control system is trying to enforce access to a resource. This leads to a Yes/No type question.  The enforcement model does not scale in a cloud or a resource constrained environment.

Entitlement model is where in the access control system does not perform enforcement or access checks. Rather it answers questions such as "What permissions does this user have?". The question seeker will then use the returned answer to perform local enforcement.

Cloud Enforcement vs Entitlement Model

References

PicketBox XACML: Open Source free implementation of OASIS XACML v2.

OASIS Cloud Authorization TC




Please do not forget to view the presentation above. :)

Is XACML really dead? Should we all go OAUTH?

Andras Cser from Forrester has a blog entry titled "XACML is dead". That is a catchy title for the blog post. :)

As a participant in the creation of OASIS XACML v3 specification (http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html) and having dabbled with an open source XACML implementation (PicketBox XACML), I would like to put forward some of my thoughts on this topic.

Let me move forward with some general questions and my answers. One of those questions will be about XACML.  After that, I am going to provide some feedback on Andras's blog entry.

Question : Is XML dead?  
Answer: Probably not. Enterprise Integration still relies heavily on XML.


Question: Is REST architecture the vogue?
Answer:  For new applications and new workflows, REST architecture is heavily favored.  To some extent, this is due to the growing importance of Cloud Technologies and APIs.



Question: Is JSON the best format for applications?
Answer: It depends on where the applications are.

For web applications and REST applications,  JSON is certainly the better format compared to XML.  But the challenge lies in securing JSON.  JSON Token Format, Signature and Encryption are still work in progress at the IETF. Bill Burke has done some excellent work with REST security at the RESTEasy project.

For enterprise applications, XML is still the norm in backend integration and configuration.



Question: Is there one security standard that I can use?
Answer:  Wishful thinking.

You can pick the best one from the following: SAML, OAuth, XACML, PKI, SSL/TLS, XML Signature/Encryption, RSA, AES and a million others.

The answer is it depends on the problem you are solving and which standard applies to the problem domain.



Question: Are there standards for access control?
Answer:  There are two standards as far as I know.

a) OASIS XACML: Language for defining access control policies. It also defines architectural elements such as PDP, PEP, PAP etc for access control infrastructure.

b) IETF OAuth2:  Authorization of resources at Internet Scale.


Question: Are SAML and XACML dead?
Answer:  It depends on who you ask.

Customers and large enterprises who have built their identity management infrastructure on SAML and XACML, will say that they are not dead.

Going by the latest buzz around cloud/mobile services, you will think OAuth is the panacea to all security problems.

SAML and XACML are standards that are pretty mainstream in enterprises and large infrastructure. They are doing their work.

Question:  Am I excited about OAuth?
Answer: Definitely.

Given that the world is going mobile heavy, OAuth is an important step in the direction of secure mobility. The future is in Cloud and APIs. Securing the APIs is what OAuth is aiming toward.

Now, for the best part, let me talk about what I think about Andras's specific points.

Andras: Lack of broad adoption.
This is a security standard.  Security standards do not get a lot of press like standards from other verticals.  XACML vendors are plenty and many customers are using XACML for their infrastructure. I certainly would like to see some additional adoption. But it is a work in progress.

Andras: Inability to serve the federated, extended enterprise
There is nothing in the XACML standard to prohibit this. It depends on the practitioners and architects.

Andras: PDP does a lot of complex things that it does not inform the PEP about.
PDP is supposed to perform the access control policy number crunching to give an answer back to the PEP's enforcement question. The answer certainly can carry obligation/advices.

I would like to bring your attention to the new TC at OASIS called the OASIS Cloud Authorization TC that I am co-chairing where we want to do a better job at defining the entitlement model compared to the classic enforcement mode (XACML/OAuth operate in).  Please refer to my use case submission called Context Driven Entitlements.

I do agree that the PEP needs more information than what it gets via the classic enforcement model.

Andras: Not suitable for cloud and distributed deployment.
I do not think this is true at all.

Andras: Commercial support is non-existent. 
It depends on who you are talking to.  There are pure XACML vendors such as Axiomatics. JBoss Middleware does have support for XACML. At the XACML interoperability events in the past, I have seen vendors such as Oracle, IBM and CA.

Andras: Refactoring and rebuilding existing in-house applications is not an option
Then those applications are doomed to fail when the requirements for access control change. I presume those applications are like "house of cards".

Andras: OAuth supports the mobile application endpoint in a lightweight manner. 
There is nothing in the XACML standard that says it cannot support lightweight workflows. Even though OAuth is more suited for mobile workflows, it should not be an issue to have XACML policy engine integrated for finer access control.  OAuth is geared toward lightweight authorization of resources under particular scopes. At internet scale, it works good. But it falls short when greater granularity of access control is needed.

Remember OAuth does not have the granularity of XACML in terms of rules (Subject, Action, Environment, Attributes). XACML is an extreme fine grained policy language framework.

References

Gerry Gebel on XACML: http://analyzingidentity.com/2013/05/08/xacml-alive-and-well/

Ray Sinnema on XACML: http://securesoftwaredev.com/2013/05/08/is-xacml-dead/

Danny Thorpe on XACML: http://dannythorpe.com/2013/05/08/xacml-is-dead-long-live-xacml/

PicketBox XACML v2.0.6.Final Released

I am pleased to announced the community release of PicketBox XACML v2.0.6.Final.

More details are available at:
http://community.jboss.org/wiki/PicketBoxXACMLJBossXACML

What is new?
1. Core RBAC Profile of XACML v2.0
2. Reading policies by just specifying the directory location in the config file.
3. Bug fixes.

Enjoy.

Usage:JBoss XACML

Project PicketBox from JBoss has an XACML engine that can be used in a Java environment.

Assuming that your configuration file is available, something like the following should work for you:

import org.jboss.security.xacml.core.JBossPDP;

import org.jboss.security.xacml.interfaces.PolicyDecisionPoint;

import org.jboss.security.xacml.interfaces.XACMLConstants;
 

//Get hold of an InputStream to the config file 

ClassLoader tcl = Thread.currentThread().getContextClassLoader();

InputStream is = tcl.getResourceAsStream( MY_CONFIG_FILE );

PolicyDecisionPoint pdp = new JBossPDP(is);

//Form your RequestContext by some means

ResponseContext response = pdp.evaluate(request);

int decision = response.getDecision();
//Decision can be one of XACMLConstants.DECISION_DENY

//XACMLConstants.DECISION_PERMIT 

RequestContext requestContext = RequestResponseContextFactory.createRequestCtx();

//Read the xacml request from input stream

requestContext.readRequest( is );

requestContext.readRequest( node );  //Parse xacml request as DOM node 

============================

If you need to look at code examples: http://community.jboss.org/wiki/XACMLPDPSOAPService

XACML Policy Editors - Domain driven or language driven

The Authorization process is extremely cumbersome and prone to errors. Typically it is rules based. Decisions based on combination of rules can lead to errors or holes. Because of errors, if the access check returns in a "denial", then the damage is minimal. Someone can verify why that particular access check got turned down.  On the contrary, if the errors lead to a successful unauthorized access, then you know the answer. :)

One of the challenges associated with configuring security is not contempt towards the field of security but the perception of complexity. Administrators/architects/developers are turned down by the number of possible combination associated in configuring ACLs/Rules.

In the Java EE world, web.xml acts as the bedrock of container driven security for web applications.  Long ago, I wrote an article on this that highlighted the permutations and combinations available to admins/devs. Ok, I am a big supporter of container based security because the opposite (custom security) is prone to errors and unmaintainable over the long run.

Coming back to configuring rules,  probably 10% of devs/architects/admins are fully versed in the XACML language and clearly understand the language. So for them a pure XACML policy editor makes sense.  The rest of the crowd just wants to configure their access control system using plain language as follows:

• This web application can be accessed by an user in the group "employee".
• This part of the web application is restricted to managers alone.
• This part of the web application is accessible under normal business hours.

Now the domain based editor for the web applications needs to have UI elements that are simple to understand. The person configuring the system will be able to look at the requirements and check/select the appropriate boxes.

While I am not denying the usefulness of a full fledged XACML policy editor, I am seriously not in agreement that they are the norm. If XACML is to see ubiquitous adoption, there is a need for configurable domain based editors. The infrastructure for access control can be driven by XACML policies and evaluation, but the policy configuration has to be driven by simple domain based editors.

References to Read:

• XACML Design Considerations and Pointers
• Travis Spencer problems with XACML and solutions
• Discussing XACML with Travis

PicketBox XACML v2.0.5.final from JBoss released

It took some extra time (other priorities took precedence). In the end, it all worked out fine.

LGPL licensed free open source project, PicketBox has released the XACML component v2.0.5.final.   Please download it from PicketBox downloads.


Main Wiki Page


PicketBox XACML Dashboard Wiki Page


Main Features Added (compared to v2.0.4)

• LDAP Based Policy Locator.
• LDAP Based Attribute Locator.
• Database Based Attribute Locator.
• Decision Cache for performance.

JIRA
PicketBox JIRA




JBoss Integration

PicketBox XACML is integrated into JBoss Application Server v5.0 and beyond.  Additionally, it is available as part of the JBoss Enterprise Application Platform (EAP) v5.0 and beyond and JBoss SOA Platform v5.0 and beyond.


Release Notes

** Bug

•     * [SECURITY-452] - Don't use Xalan classes directly. Use Java API instead
•     * [SECURITY-461] - AttributeFinder:findAttribute method can throw an NPE if any of the attribute finder modules return null
•     * [SECURITY-462] - JBossRequestContext should throw IllegalArgumentException for null inputstream
•     * [SECURITY-507] - JBossXACML: anyURI mismatch
•     * [SECURITY-518] - JBossPDP should be serializable

** Feature Request

•     * [SECURITY-454] - Database Attribute Locator
•     * [SECURITY-463] - AttributeValue.getValue abstract method * [SECURITY-455] - LDAP based attribute locator
•     * [SECURITY-456] - File based Attribute Locator
•     * [SECURITY-492] - JBossPolicySetLocator should gracefully handle policies
•     * [SECURITY-516] - Create a LDAP policy provider for JBoss XACML
•     * [SECURITY-521] - Decision Cache for constant XACML Requests
•     * [SECURITY-522] - XACML add hashcode and equals to RequestCtx, Attribute
•     * [SECURITY-525] - XACML Attribute Locator should support comma separated list of attributeSupportedIds                                                                                                         

XACML Design Considerations and Pointers

One of the challenges with XACML has been the deep knowledge/expertise required in understanding the XACML vocabulary. It can send shivers down anybody's spine when they come across a bunch of XACML policies. While the language is extremely powerful, lack of editors has been the bane.

While it is difficult to design a general purpose xacml editor without requiring the user to have extensive xacml knowledge, it should definitely be possible to create context based editors for XACML rules.  Suppose you are creating XACML policies for your web application, then you can have an editor that is specific to the web application domain.  This domain based editor approach will avoid the requirement of xacml knowledge. The policies can be designed in the domain semantics.

If you have some free time to kill and want to understand XACML better, I certainly recommend taking a peak at the Fedora XACML document ( I did not write it or was associated with the project).


Design Consideration

One of the favorite topics broached by XACML designers is the concept of date/time as part of the environment attributes.

You should be able to create XACML policies with rules such as:

• Deny requests to web applications between 5pm and 8am CDT.

One point you need to note here is that if you are setting up automated tests to validate your policies, then the time at which the PDP is running your tests, can affect the outcome of the test result.

You should embed the current time as part of your XACML request during tests such that they simulate a request occurring at a particular time - rather than when the test is run. :)

You should definitely take a look at the XML Date and Time functions including Timezone configuration as listed here.

Tip: Debugging JBossXACML/PicketBox XACML

JBossXACML Debugging

If you are looking at getting debug information for the rule evaluation:


JBoss AS Environment :

Add a TRACE level logging category in conf/jboss-log4j.xml(AS5+) or deploy/jboss-logging.xml (AS6+)

<category name="org.jboss.security.xacml">
<priority value="TRACE"/>
</category>



Non-JBoss AS Environment such as Apache Tomcat :

Try to create a logging.properties file
============================
# Specify the handlers to create in the root logger
# (all loggers are children of the root logger)
# The following creates two handlers
handlers = java.util.logging.ConsoleHandler, java.util.logging.FileHandler

# Set the default logging level for the root logger
.level = ALL

# Set the default logging level for new ConsoleHandler instances
java.util.logging.ConsoleHandler.level = ALL

# Set the default logging level for new FileHandler instances
java.util.logging.FileHandler.level = ALL

# Set the default formatter for new ConsoleHandler instances
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter

# Set the default logging level for the logger named org.jboss
org.jboss.security.xacml.sunxacml.level = FINEST
com.sun.xml.bind.level = OFF
=====================================================

Now pass the system property with the location of this file such as:
-Djava.util.logging.config.file=src/test/resources/logging.properties

Then you should see something like:
=========================================
Mar 30, 2009 3:38:25 PM org.jboss.security.xacml.sunxacml.combine.StandardCombiningAlgFactory initAlgorithms
CONFIG: Initializing standard combining algorithms
Mar 30, 2009 3:38:25 PM org.jboss.security.xacml.sunxacml.cond.StandardFunctionFactory initGeneralFunctions
CONFIG: Initializing standard General functions
Mar 30, 2009 3:38:25 PM org.jboss.security.xacml.sunxacml.cond.StandardFunctionFactory initConditionFunctions
CONFIG: Initializing standard Condition functions
Mar 30, 2009 3:38:25 PM org.jboss.security.xacml.sunxacml.cond.StandardFunctionFactory initTargetFunctions
CONFIG: Initializing standard Target functions
Mar 30, 2009 3:38:25 PM org.jboss.security.xacml.sunxacml.PDP
FINE: creating a PDP
Mar 30, 2009 3:38:25 PM org.jboss.security.xacml.sunxacml.finder.PolicyFinder init
FINER: Initializing PolicyFinder
Resource must contain resource-id attr
Mar 30, 2009 3:38:25 PM org.jboss.security.xacml.sunxacml.cond.Apply evaluate
FINE: Function:urn:oasis:names:tc:xacml:1.0:function:string-bag-size:
:::result=2
Mar 30, 2009 3:38:25 PM org.jboss.security.xacml.sunxacml.cond.Apply evaluate
FINE: Function:urn:oasis:names:tc:xacml:1.0:function:integer-equal:


::org.jboss.security.xacml.sunxacml.attr.IntegerAttribute@0:::result=false
Mar 30, 2009 3:38:25 PM org.jboss.security.xacml.sunxacml.cond.Apply evaluate
FINE: Function:urn:oasis:names:tc:xacml:1.0:function:not:



0

:::result=true
Mar 30, 2009 3:38:25 PM org.jboss.security.xacml.sunxacml.cond.Apply evaluate
FINE: Function:urn:oasis:names:tc:xacml:1.0:function:string-subset:
::
:::result=true
Mar 30, 2009 3:38:25 PM org.jboss.security.xacml.sunxacml.cond.Apply evaluate
FINE: Function:urn:oasis:names:tc:xacml:1.0:function:not:



:::result=false
Mar 30, 2009 3:38:25 PM org.jboss.security.xacml.sunxacml.cond.Apply evaluate
FINE: Function:urn:oasis:names:tc:xacml:1.0:function:and:

0
::

:::result=false
Mar 30, 2009 3:38:25 PM org.jboss.security.xacml.sunxacml.combine.DenyOverridesRuleAlg combine
FINE: Rule id:urn:oasis:names:tc:xspa:1.0:org:allowed:organizations:deny:result=3
Mar 30, 2009 3:38:25 PM org.jboss.security.xacml.sunxacml.cond.Apply evaluate
FINE: Function:urn:oasis:names:tc:xacml:1.0:function:time-one-and-only:
:::result=15:38:25.553000000-05:00
Mar 30, 2009 3:38:25 PM org.jboss.security.xacml.sunxacml.cond.Apply evaluate
FINE: Function:urn:oasis:names:tc:xacml:1.0:function:time-one-and-only:
:::result=00:00:00-08:00
Mar 30, 2009 3:38:25 PM org.jboss.security.xacml.sunxacml.cond.Apply evaluate
FINE: Function:urn:oasis:names:tc:xacml:1.0:function:time-greater-than-or-equal:
::
:::result=true
Mar 30, 2009 3:38:25 PM org.jboss.security.xacml.sunxacml.cond.Apply evaluate
FINE: Function:urn:oasis:names:tc:xacml:1.0:function:not:

:::result=false
Mar 30, 2009 3:38:25 PM org.jboss.security.xacml.sunxacml.cond.Apply evaluate
FINE: Function:urn:oasis:names:tc:xacml:1.0:function:time-one-and-only:
:::result=15:38:25.553000000-05:00
Mar 30, 2009 3:38:25 PM org.jboss.security.xacml.sunxacml.cond.Apply evaluate
FINE: Function:urn:oasis:names:tc:xacml:1.0:function:time-one-and-only:
:::result=23:59:00-08:00
Mar 30, 2009 3:38:25 PM org.jboss.security.xacml.sunxacml.cond.Apply evaluate
FINE: Function:urn:oasis:names:tc:xacml:1.0:function:time-less-than-or-equal:

::

:::result=false
Mar 30, 2009 3:38:25 PM org.jboss.security.xacml.sunxacml.cond.Apply evaluate
FINE: Function:urn:oasis:names:tc:xacml:1.0:function:not:


:::result=true
Mar 30, 2009 3:38:25 PM org.jboss.security.xacml.sunxacml.cond.Apply evaluate
FINE: Function:urn:oasis:names:tc:xacml:1.0:function:or:


::


:::result=true
Mar 30, 2009 3:38:25 PM org.jboss.security.xacml.sunxacml.combine.DenyOverridesRuleAlg combine
FINE: Rule id:urn:oasis:names:tc:xspa:1.0:org:hoursofoperation:deny:result=1
=============================

This is very good debug information.

XACML with ExistDB Integration

I was recently asked about Exist DB support for PicketBox XACML (formerly JBossXACML) mainly to retrieve missing XACML attributes during policy evaluation. The question was asked by one of our beta testers of PicketLink (http://jboss.org/picketlink).

We now have ExistDB integration support for our XACML Engine. You can read about it here:
PicketBox XACML Integration with Exist DB

I think storing xml files (policies) in an XML native database is a fine idea as long as it is a small set.

SAML and XACML standards in US Healthcare

I was fortunate to utilize PicketLink (http://jboss.org/picketlink) in a Technology Demonstration (interoperability exercise) at HIMSS 2009, April 2009 at Chicago. The other participants were Sun Microsystems, Jericho Systems, US Department of Veterans Affairs and the US Department of Defense. I have reported on this in the past. We used PicketLink mainly for the SAML and XACML capabilities. The associated Oasis press release is OASIS and HITSP Collaborate on Interoperability Demo of Healthcare Privacy Standards at HIMSS09.

While we are on the topic, I am extremely glad to read the latest news item from the Oasis Consortium related to the use of XACML and SAML standards in the US Healthcare infrastructure. The news is OASIS Members Approve Security and Privacy Authorization Standards for Healthcare.

As co-chair of the Oasis XSPA Technical Committee that was the driver of the two profiles (one on SAML and one on XACML) that became Oasis standards recently, I was able to contribute and support these two profiles. I am pleased that Oasis XACML and Oasis SAML standards have made headway into being mandated for use in the US Federal Agencies. Hopefully, these two standards should play a pivotal role in the widespread usage of the National Health Information Network (NHIN), whose open source based initiative is CONNECT.

JBossXACML v2.0.4 Released

You can get JBossXACML v2.0.4 with minor performance improvements from
http://jboss.org/jbosssecurity/downloads/JBoss%20XACML/?action=a&windowstate=maximized

==================
** Feature Request
* [ SECURITY-423 ] RequestAttributeFactory should have method for multi valued attributes
* [ SECURITY-424 ] Schema Entity Resolver to resolve to local XACML schemas
* [ SECURITY-425 ] Ability to disable JBossXACML Schema Validation
* [ SECURITY-431 ] JAXBContext should be cached in JBossPDP

** Release
* [ SECURITY-432 ] Release JBossXACML 2.0.4
=====================

FAQ:
1) I want to use the latest JBossXACML jar in JBoss AS 5.x
- You need to replace the jbossxacml.jar with the one from this release from the lib directory of your JBoss AS instance. Note if you have a jboss-sunxacml.jar in the lib directory also, discard it.

SAML2/XACMLv2 Out of the Box

Suppose you have the following needs:
a) Need to have XACMLv2 evaluation of access control requests.
b) Do not want to implement either the XACML PDP (Policy Decision Points) or PEP (Policy Enforcement Points).
c) Use SAMLv2 payload to transport the XACMLv2 request and response.
d) Use SOAP 1.1 messages to carry the SAMLv2 payload (which internally carries the XACMLv2 request/response messages).

As described in SAMLv2/XACMLv2 integration, there is a servlet provided as part of the JBossIdentity stack.

All you need to do is create the XACML policies and package it as part of a web application and configure the SOAPSAMLXACMLServlet in the web.xml as defined in the wiki article.

You get out of the box functionality without a need to write PDP or PEP. The servlet acts as the PEP/PDP combo.

JBossXACML v2.0.3 Released

Since we had a very successful interoperability experience as part of the Oasis-HITSP Technology Demonstration at HIMSS2009 in Chicago, we are ready to roll the next version of JBossXACML.

JBossXACML v2.0.3 should be available from here. (Click <==)


Release Notes:
==========================
Release Notes for JBoss Security and Identity Management
Includes versions: JBossXACML_2.0.3.alpha JBossXACML_2.0.3.CR1 JBossXACML_2.0.3.CR2 JBossXACML_2.0.3.CR3 JBossXACML_2.0.3.CR4 JBossXACML_2.0.3 JBossXACML_2.0.3.CR5

** Sub-task
* [ SECURITY-390 ] JBossXACML: ResourceLocator
* [ SECURITY-396 ] Rule:: NPE if description of a rule is empty
* [ SECURITY-400 ] XACML Conformance Tests: Mandatory - attribute references, functions, combination algos
* [ SECURITY-401 ] XACML Conformance Tests: Mandatory - schema components

** Feature Request
* [ SECURITY-257 ] AttributeDesignator should throw RuntimeException when a particular attribute that was expected is missing
* [ SECURITY-275 ] JBossSAMLRequest: buildRequest method
* [ SECURITY-382 ] JBossPDP ctr to take Configuration Metadata also
* [ SECURITY-388 ] JBossXACML: AttributeLocator
* [ SECURITY-407 ] XACML: Configuration should allow specifying just the locators (and no policies)

** Bug
* [ SECURITY-206 ] Attribute type not set in constructor
* [ SECURITY-295 ] NPE in JBossPDP -> createValidatingUnMarshaller when schema is missing
* [ SECURITY-351 ] JBossResponseContext->getResult has missing values
* [ SECURITY-391 ] JBossXACML: PDP construction should be one time
* [ SECURITY-394 ] FunctionBase: bag-size throws an IllegalArgumentException
* [ SECURITY-395 ] AbstractPolicy: Empty Description element throws NPE
* [ SECURITY-397 ] XACML: HigherOrderFunction checkInputs needs to relax type checking on evaluations
* [ SECURITY-399 ] XACML: Apply->evaluate method tries to encode an attributeValue that can be a bag
* [ SECURITY-403 ] XACML: Resource can have multiple attributes with resource-id
* [ SECURITY-405 ] XACML:: TimeAttribute computes GMT miliseconds incorrectly when the date is 1 day after Jan 1, 1970

** Task
* [ SECURITY-335 ] Sync up sunxacml bug fixes
* [ SECURITY-337 ] Validate the Oasis XACMLv2 conformance tests
* [ SECURITY-359 ] Retire jboss-xacml-saml module
* [ SECURITY-360 ] Assembly for jbossxacml
* [ SECURITY-409 ] Release JBossXACML 2.0.3
==============================================================

What is new?
* Some performance improvements in the PDP evaluation. Previously we were creating a PDP per evaluation. Now we instantiate a PDP and then use it for each evaluation. (Call this an oversight. We are human!).
* You can specify just locators (policy, attribute or resource) in the configuration file without the need for specifying the policy/policysets. This is useful when you need to write a locator that needs to fetch a policy or attribute from a different location.
* The Oasis v2 Conformance Tests are now part of the JBossXACML test suite. So every release will ensure that we have conformance.

User Guide: http://www.jboss.org/auth/jbosssecurity/docs/jbossxacml/html/jbossxacml.html

JBossXACML 2.0.3.CR5 released

http://www.jboss.org/jbosssecurity/downloads/JBoss XACML

Pick the JBossXACML CR5 version from the xacml downloads section (Ignore the download counter as it is not working).

Bugs Fixed:
SECURITY-403 XACML: Resource can have multiple attributes with resource-id
SECURITY-405 XACML:: TimeAttribute computes GMT miliseconds incorrectly when the date is 1 day after Jan 1, 1970

If you are interested in adding this to JBossAS 5.0.x, then from the common/lib directory, remove the (jboss-xacml.jar and jboss-sunxacml.jar) and place jbossxacml.jar there.


User Guide: http://www.jboss.org/auth/jbosssecurity/docs/jbossxacml/html/jbossxacml.html

JBossXACML 2.0.3.CR3 released

The next iteration of JBossXACML in the 2.0.3 is available now. It can be downloaded from the downloads page here:
http://www.jboss.org/jbosssecurity/downloads/JBoss%20XACML

====================
Release Notes for JBoss Security and Identity Management
Includes versions: JBossXACML_2.0.3.CR3

** Sub-task
* [ SECURITY-390 ] JBossXACML: ResourceLocator

** Feature Request
* [ SECURITY-388 ] JBossXACML: AttributeLocator

** Bug
* [ SECURITY-391 ] JBossXACML: PDP construction should be one time

** Task
* [ SECURITY-392 ] Release JBossXACML 2.0.3.CR3
=========================================

That is the release notes.

Improvements in 2.0.3.CR3:
* Support for specifying Attribute Locators and Resource Locators.
* Minor performance improvement where the internal pdp is constructed one time rather than at each request evaluation.

What are Attribute Locators?
Attribute Locators are consulted when the Policy specifies certain attributes to be necessary for evaluation and the the request comes without the required attribute. In that case, the PDP is going to ask the attribute locator for a value for the attribute to make an evaluation. Again, remember the attribute locator is driven by the POLICY and not the REQUEST.

Procedure for Attribute Locators:

• Write a subclass of org.jboss.security.xacml.locators.AttributeLocator
• The following methods need to be overridden in your attribute locator
  * @see AttributeFinderModule#findAttribute(String, org.w3c.dom.Node, URI, org.jboss.security.xacml.sunxacml.EvaluationCtx, String)
  * @see AttributeFinderModule#findAttribute(URI, URI, URI, URI, org.jboss.security.xacml.sunxacml.EvaluationCtx, int)
• Then specify the attribute locator in your configuration file as shown in the example below.
  
  

Resource Locators
These are used in the Hierarchical Profile if you decide to use it.

Configuration File

=================================
<ns:jbosspdp xmlns:ns="urn:jboss:xacml:2.0">
<ns:Policies>
<ns:PolicySet>
<ns:Location>test/policies/interop/xacml-policySet.xml</ns:Location>
<ns:Policy>
<ns:Location>test/policies/interop/xacml-policy2.xml</ns:Location>
</ns:Policy>

<ns:Policy>
<ns:Location>test/policies/interop/xacml-policy3.xml</ns:Location>
</ns:Policy>
<ns:Policy>
<ns:Location>test/policies/interop/xacml-policy4.xml</ns:Location>
</ns:Policy>

<ns:Policy>
<ns:Location>test/policies/interop/xacml-policy5.xml</ns:Location>
</ns:Policy>

</ns:PolicySet>
</ns:Policies>
<ns:Locators>
<ns:Locator Name="org.jboss.security.xacml.locators.JBossPolicySetLocator"/>

<ns:Locator Name="org.jboss.test.security.xacml.locators.TestAttributeLocator">
<ns:Option Name="identifier">test-attrib</ns:Option>
<ns:Option Name="attributeDesignatorSupport">true</ns:Option>
<ns:Option Name="attributeSelectorSupport">true</ns:Option>
<ns:Option Name="attributeDesignatorInt">0</ns:Option>
<ns:Option Name="attributeDesignatorInt">1</ns:Option>
<ns:Option Name="attributeDesignatorInt">2</ns:Option>
<ns:Option Name="attributeSupportedId">urn:oasis:names:tc:xacml:1.0:action:action-id</ns:Option>
<ns:Option Name="attributeSupportedId">http://www.w3.org/2001/XMLSchema#string</ns:Option>
<ns:Option Name="attributeSupportedId">urn:xacml:2.0:interop:example:subject:buy-offer-price</ns:Option>
<ns:Option Name="attributeSupportedId">urn:oasis:names:tc:xacml:1.0:subject:subject-id</ns:Option>
</ns:Locator>

<ns:Locator Name="org.jboss.test.security.xacml.locators.TestResourceLocator">
<ns:Option Name="identifier">test-resource</ns:Option>
<ns:Option Name="resourceChildSupport">true</ns:Option>
<ns:Option Name="resourceDescendantSupport">true</ns:Option>
</ns:Locator>

</ns:Locators>
</ns:jbosspdp>
=================================

The "Option" element tags are got from AbstractLocator interface.
http://anonsvn.jboss.org/repos/jbossas/projects/security/security-xacml/tags/2.0.3.CR3/jboss-xacml/src/main/java/org/jboss/security/xacml/interfaces/AbstractLocator.java

------------------------

   String IDENTIFIER_TAG = "identifier";
 
  String ATTRIBUTE_DESIGNATOR_SUPPORT_TAG = "attributeDesignatorSupport";
 
  String ATTRIBUTE_SELECTOR_SUPPORT_TAG = "attributeSelectorSupport";
 
  String ATTRIBUTE_SUPPORTED_ID_TAG = "attributeSupportedId";
 
  String ATTRIBUTE_DESIGNATOR_INTEGER_TAG = "attributeDesignatorInt";
 
  String RESOURCE_CHILD_SUPPORTED_TAG = "resourceChildSupport";
 

  String RESOURCE_DESCENDANT_SUPPORTED_TAG = "resourceDescendantSupport";

================================


User Forum: http://www.jboss.org/index.html?module=bb&op=viewforum&f=49

JBossXACML 2.0.3.CR1 released

I would like to announce the availability of JBossXACML v2.0.3.CR1 release. You can get to it from the downloads page here:
JBossXACML Download

What does this have over the last v2.0.2.SP1 release?
* Bug fixes.
* Consolidation of jboss-xacml.jar and jboss-sunxacml.jar into one jar - jbossxacml.jar
* Discontinuation of the jboss-xacml-saml.jar as this functionality is currently provided by JBossIdentity.

As always, please provide feedback at the user forum.

FAQ:
1) How do I use this CR1 jar in AS5.x?
AS5.0.0.GA and 5.0.1.GA contain the v2.0.2.SP1 release of JBossXACML. Just replace the jboss-xacml.jar and jboss-sunxacml.jar from common/lib directory with the jbossxacml.jar

2) Are there any tutorials?
http://java.dzone.com/articles/fine-grained-web-authorization

Survey: Do you use JBoss XACML?

I am trying to get a sense of usage of JBoss XACML either as a standalone project or inside JBoss Application Server v5.0. If you are using this project, please choose any of the 3 options. Takes less than 10 seconds.

The survey is available on the Left Hand Column of http://anil-identity.blogspot.com


Reference:

What is JBoss XACML?
Refer to:
https://www.jboss.org/community/docs/DOC-10840

What is Oasis XACML?
Refer to:

http://en.wikipedia.org/wiki/XACML

Can I use JBossXACML without using the JBoss Application Server?
Of course, it is a standalone project.
Pick your jars from the following two places for the latest version:
http://repository.jboss.org/maven2/org/jboss/security/jboss-xacml/
http://repository.jboss.org/maven2/org/jboss/security/jboss-sunxacml/



=======================

AS5: Fine Grained Authorization using Oasis XACML (Part 1)

Access Control is one of my favourite topics in security. There are two aspects to it - coarse grained and fine grained access control. 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).

I am sure you can google XACML and learn more about it.

The good news is that JBoss Application Server v5.0 bundles JBossXACML v2.0.2.SP1. What does this mean? It means that you now have capabilities to extend your container authorization mechanism to include XACML policies shipped with your web/ejb deployments. Apart from this, if you need to do your own security work in your applications and looking for a XACML stack, then you can use the friendly JBossXACML api to create policies, do evaluations etc.

Please wait for Part 2 of this post to read more about using XACML for your web and ejb container authorization.

Oasis SAML and XACML Presentation

I am going to be making a presentation on Oasis SAML and XACML at the ExpeditionWorkshop (Exploring Identity Management Landscape) at NIST.

The workshop page is located here.

If you would like to take a peek at my presentation, then click here.

Oasis SAML v2 is a specification that deals with Federated Identity and Oasis XACML v2 is a specification that deals with access control.

Examples:
If you need to take a peek at SAML2 payload carrying XACML2 request/response, then please take a look at my other post.