SAML vs OAuth: Which one to use?

Please follow my DZone article on this important topic: http://architects.dzone.com/articles/saml-versus-oauth-which-one

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/

JAX-RS and HTTPOnly flag in Cookies

JAX-RS in Java

JAX-RS is an important technology/standard/specification in the JavaEE family. Version 1.1 is included in Java EE 6. JAX-RS enables Java applications to become REST enabled.

Currently JAX-RS v2.0 specification work is under development in the JCP.

HttpOnly Flag

HttpOnly flag in cookies sent from the server have an important behavior on the client side (browser based applications). Javascript applications cannot access the cookies marked with HttpOnly flag.

This is a non-standard flag in the cookie standard.  But all the major browser implementations support this. So it is important for all Java server runtimes and frameworks that deal with cookies to support HttpOnly.

JavaEE6 has support for HttpOnly via the Servlet3 specification as well as support for configuration in the web.xml cookie-config xml element.

JAX-RS 2.0 has been updated to incorporate HttpOnly flag in the NewCookie class (http://lists.jboss.org/pipermail/security-dev/2013-February/000783.html) Thanks to Bill Burke. [ Bill Burke created a JIRA issue with the spec: http://java.net/projects/jax-rs-spec/lists/issues/archive/2013-02/message/0 )]

HttpOnly in JAX-RS

For Jax-RS 1.1 (included in Java EE 6), you will need to do something like the following:

=============
NewCookie cookie = new NewCookie(...);
Response response = Response.ok().header("Set-Cookie", cookie.toString()+ ";HttpOnly").build();
=============

Example: https://github.com/picketlink/picketlink-extensions/blob/master/core/src/main/java/org/picketlink/extensions/core/rest/interceptors/PostSignInCookieInterceptor.java

RESTEasy project has ServerResponse that extends JAX-RS Response class.  This class is very important for pre and post processing interceptors.

References

1. RESTEasy
2. JAX-RS discussion on HttpOnly
3. PicketLink discussion on RESTEasy/HttpOnly