Proposal for Access Control Services
Thomas Edison
I am submitting a proposal for fine-grained access control to the Cloud Foundry foundation for consideration. The foundation recommended that I post on this forum to get input from the larger community. You can read the proposal here:
https://docs.google.com/document/d/15WKI10Rt6ktRwDJO1mi4lMgn8bKpRohYRXBk2ZDNjDo/edit?usp=sharing
The proposal describes, at a high level, a solution that allows developers to create Cloud Foundry based RESTful services with fine-grained authorization policies. Your input is appreciated.
Sree Tummidi
--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/a077dc2b-2c92-42ee-b03c-80054f6faf5e%40cloudfoundry.org.
To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.
James Bayer
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CANNZs1QqOe5zC4LzgONfwOzcqfxLh2Jw2d1L_%3DEhWr6Y_hJA9Q%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.
Thomas Edison
Oversight on my part. Here is a link that allows comments:
https://docs.google.com/document/d/15WKI10Rt6ktRwDJO1mi4lMgn8bKpRohYRXBk2ZDNjDo/edit?usp=sharing
Let me know if there are any problems with that link. BTW you can call me Dario.
Thomas Edison
Building authz as a route service was also something that had occurred to me after reading their proposal. Will route service allow for the injection of additional custom headers when re-writing an HTTP request?
On Monday, March 30, 2015 at 11:18:27 AM UTC-7, jbayer wrote:
Deepak Vij
Few observations & comments:
1) Based on my experience, I thought XACML has kind of become quite prevalent policy standard for building interoperable authorization system - a standard based language for expressing information system authorization policies. Quite a number of I&AM vendors have adopted XACML standard for authorization policies representations. Especially, the fact that XACML also allows support for Attribute-based access control as opposed to traditional fixed “role” assignment (RBAC). RBAC model in the dynamic environment becomes quite restrictive and ad-hoc exercise (manufactured roles engineering etc.). Although, in your document you mentioned that you experienced weakness in XACML standard. I am curious to know what your observations are as far as weaknesses of XACML are concerned.
2) 2) Secondly, there are already few good open source access control engines available (ForgeRock OpenAM, Apache Shiro, & JoshuaTree Fortress). Worth looking into these options versus re-inventing the wheel and unnecessarily huge amount of work.
3) 3) Lastly, fine-grained access control goes beyond merely restricting certain URLs access. Data Visibility is a very key requirement as well in the enterprise environment. Data visibility capability enables granular data level access control whereby for example a manager can see all his/her employees data while employees, on the other hand, can only see their own data. This could be based on role based hierarchies (top-down & bottom-up). Essentially, “Data Visibility” means “who can see what” data. In order to achieve fine-grained “Data Visibility”, one would have to dynamically generate SQL by interpreting the access rules as part of policy definitions in conjunction with the user role. There are two different approaches for accomplishing this - API Callout Approach & Data Guard Approach.
API Callout Approach – This is an intrusive approach whereby the SQL query,
for example, is modified by issuing an API callout at the data layer level to
the XACML based access control system. The data returned is therefore the data
the user is actually authorized to see/update. ForgeRock OpenAM follows this particular approach in order to enforce
granular fine-grained access control.
Data Guard Approach – This is a non-intrusive approach whereby the SQL query,
for example, is intercepted at the data layer level. The query is then processed
against XACML access policies and subsequently modified with the appropriate
where clause. The data returned is therefore the data the user is actually
authorized to see/update. This is a very dynamic and non-intrusive approach
that permits ease of implementing changes and also provides the required
granular control. Commercial products such as Oracle
Identity & Access management provide support for non-intrusive “data Guard”
approach in order to enforce granular fine-grained access control.
Thomas Edison
Hi Deepak, thanks for your input. I'll try to address your points one by one.
1) For the past year and a half or so, my team helped develop a platform that uses a popular open source XACML engine (I will omit the name since I don't believe it's essential to the point I am about to make). During that time, I had the opportunity to observe the reaction of several development teams building on top of our platform to the XACML standard. Here's a brief overview of my impressions.
a. It's too complex - Some teams simply gave up on XACML. XACML is a very powerful standard that provides ABAC. However, most applications don't need this power. Unfortunately, if all your application requires is more traditional RBAC, which I would describe as a subset of ABAC, it's still complicated to do this with XACML. Specifically, the learning curve associated with XACML is high and the amount of energy expended learning XACML seems to exceed the benefit for teams looking for a simple solution. It would make more sense if the complexity of the solution was incremental with respect to the complexity of the problem that needs to be solved.
b. It's unintuitive - On more than one occasion, I have noted that teams misunderstood how to leverage the power of XACML. For example, I would often hear complaints that "XACML does not scale" because every time they created a user or added a resource they had to create additional policies. What developers would often miss is the capability to define functional logic within the XACML policy definition that could compare user and resource attributes to create dynamic access control policies. Besides the notable absence of educational information on XACML, I think another reason developers would run into these kind of problems is due to the unintuitive nature of writing XACML policies. One example of this is having to write functional logic in XML. When developers think XML they tend to think configuration - not logic. In XACML a one line regex becomes at dozen lines of XML
c. XML - Policies written in XML are painfully verbose. Also there are a whole host of issues that plague XML related to normalization, parsing, efficiency, and troubleshooting. While there is a JSON profile for XACML, I don't see much adoption of it, and it still doesn't seem intuitive for expressing access control logic.
d. PIP integration - The two XACML implementations that I have first hand experience with, have limited capabilities for managing user attributes (usually tied to LDAP directories in ways that essentially boils down to RBAC), and no ability whatsoever to manage resource attributes. Which means that developers end up implementing their own XACML PIP to manage user and resource attributes. This is a significant burden on development teams.
2) I have minimal exposure to ForgeRock OpenAM and Apache Shiro but I have never heard of Joshua Tree Fortress. I don't believe OpenAM or Apache Shiro have the same capabilities as those described in my proposal. However, I agree with you on not having to re-invent the wheel, so I'll do some more digging. In the meanwhile, if there is a specific capability that you are referring to please point that out. There are, obviously, many authorization solutions. However, I don't know of any that fill all the requirements outlined in the proposal I submitted.
3) I understand your point about data visibility. To help solve this problem, our proposal describes a security context delivered to the application logic that would contain all of the information necessary to enforce the appropriate data visibility. However, we have not settled on a proposal for how we would enforce data visibility based on the security context, though we have entertained ideas of doing it at the data layer level. One concern with this approach is how to provide a solution that is language agnostic.
Finally, while it's great to know that there are open source and commercial solutions to these problems, we're testing the waters to see if it makes sense to propose a solution that can gain consensus with the Cloud Foundry community and possible even standardization in the long term.
Deepak Vij
Hi Thomas, this is in regards to your comment regarding XCAML being complex and XML based verbose. This is more of a tooling issue. I believe commercial vendors such as Axiomatics etc. have addressed this issue by providing easy-to-use authoring tooling (plug-in into eclipse etc.). As I said before, let us not restrict ourselves to fixed “role” based assignment using RBAC. In the next generation Intercloud and IoT like highly dynamic environment, RBAC model becomes quite restrictive and ad-hoc exercise (manufactured roles engineering etc.).
Dario Amiri
I feel that a tooling based solution is missing the point. If there is a simpler way to solve a problem why not pursue that? Why solve complexity by wrapping it in tooling which makes the overall system more complex? Especially, why build a system that has to rely on a commercial vendor to provide the tooling necessary to make it easy to use?
Pardon me for using analogies, but I've heard this tooling argument before regarding technologies such as SOAP, WS-*, EJB, OSGi, etc. At some point an issue occurs where you need get past the tooling (troubleshooting, debugging, performance tuning, etc.) and then you're left struggling with a system that's difficult to understand, difficult to teach, and difficult to adapt.
I'm not a proponent of reinventing the wheel, but when you've seen the pain that XACML inflicts on developers for as long as I have you have to start wondering if there's a better way. Not to get too emotional, I'm happy to incorporate any aspects of XACML that make sense but we need to evolve the things that don't.
Sree Tummidi
Hi Dario,
Thank you sharing the proposal on the finer grained authorization services for UAA. I apologize for the delay in getting back with the response. Reviewing the proposal you put out has highlighted some bigger gaps with UAA around basic authorization which need to be addressed before we can move to solve advanced authorization use-cases.
UAA at this time doesn’t process claims about the user which is key to the downstream authorization decisions. We have plans to address these gaps in the coming weeks/months and create a robust framework for handling user claims from external identity providers.One of the other things which is missing in UAA is the concept of policy based token issuance.
We have a route services feature coming up which will allows for the interception of the router calls before they hit the App/Container. We would like to leverage this feature to applying basic authentication and authorization filters for the applications running on the Cloud Foundry platform.
In summary, we would like to start by filling in these basic gaps which exist in UAA today and support basic authorization use cases before moving on to the more advanced ones.I definitely see opportunities for us to collaborate on these topics above in the near future.
We will start by putting out proposal for user claims processing and policy based token issuance for review by the community.
Please feel to reach out further on this topic.
Thanks,
--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/6a283027-8bf9-4bd8-b7a7-e72b0bc0ea8a%40cloudfoundry.org.
Dario Amiri
Thanks for the response. There are a few things which you mentioned that I would like to address.
“UAA at this time doesn’t process claims about the user which is key to the downstream authorization decisions.”
This is a good point and it’s a capability that our customers have asked for. It’s also a problem that’s easy to work around through user provisioning, which we have done successfully, and thus is not a major pain point (at least for our customers). Meanwhile, lack of fine-grained access control is a show-stopper for developers that want to build cloud foundry applications in the healthcare, energy, and aviation businesses.
“We have a route services feature coming up which will allows for the interception of the router calls before they hit the App/Container. We would like to leverage this feature to applying basic authentication and authorization filters for the applications running on the Cloud Foundry platform.”
This is exactly what I am proposing, which is why I think it behooves us to continue this discussion. I understand that there are other items in the UAA backlog. However, if I can’t persuade you to adjust priorities, we can at least continue to discuss potential solutions to the problem. Even if all we accomplish is consensus on the best patterns for solving the problem, that has two major benefits: 1) it provides guidance to a community that is building their own solutions to the problem 2) it reduces the friction of migrating to a future cloud foundry solution (e.g. if we can define a policy format then we can remove a major barrier of moving from one implementation to another).
In essence, it sounds like you agree that this is a really problem that needs a solution, so it seems like common sense that we should keep the discussion going.
Sree Tummidi
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/d0e40f95-914b-4cef-a0a7-f306ea4e4a07%40cloudfoundry.org.