Currently i'm working in a on-line payment company, i need to implement a access control system. I used XACML for experimental purpose 2 years ago, and used it in a management system(based on Balana's XACML implementation). I noticed XACML Version 3 specification hasn't been updated since Jan 2013, i wonder whether this specification is still under maintenance. If not, does anyone know any alternative?
What David says is correct. In addition, the OASIS XACML Technical Committee (TC) has just voted to hold a public review of Errata for XACML 3.0. The review should start within a few days. The corrections are minor, but it does show we are maintaining the documents and getting input from the field.
Although no one is currently working on them, there are several unfinished Profiles I would like to see completed. One is to extend the JSON format for XACML to cover the policy language. It currently only covers only the decision request protocol. Another is the ALFA policy language which is a more user friendly, JSON-like language originally developed by Axiomatics, and endorsed by the TC.
For people who want to use XACML, in addition to several excellent commercial products, there are at least two other open source implementations in addition the the WS02 - Balana one mentioned above. Forgerock has one and there is another originally developed in house at ATT. The later one was contributed to the Apache Incubator, but failed to gain traction and was mothballed. However the original code is still freely available under Apache license.
Finally I should mention that I have proposed various ways to integrate XACML with token-based authorization schemes such as OAuth. However this has not gone past the research stage.
Yes, XACML is still very much active. The standard, in version 3, is mature and right now no one is working on XACML 4.0. Given XACML 3.0 is a standard, there won't be changes made to 3.0. Either we go to 3.1 or 4.0. There are enhancements we are thinking of for a 4.0 version but this is not the focus for now.
The focus is on profiles, both technical profiles (such as the JSON profile of XACML) and business profiles (such as the Export Control profile of XACML).
Disclaimer: I work for Axiomatics, the leading XACML implementation. I am also a member of the XACML Technical Committee.
We see more and more requests for Attribute Based Access Control and XACML in the marketplace especially in financial and healthcare
Related
I'm developping an open source OTA update system for a few MCUs of a certain project. I wonder if there is some "standard" protocol for CAN-bus based bootloaders. Everything I saw online and in Application Notes from the chip manufacturers seem to be using their own brand of communication and thus their own specialized upload software too (mainly for demonstration for ANs).
My question is, am I missing something? Is there some standard way of doing this I'd rather adhere to, or should I just roll my own like they do and call it a day?
Features I'm interested in for the protocol side besides the obvious ones: checksumming, digital signatures, authenticated encryption.
Based on your tag, despite I do not see this from your question, I assume for now that you want to develop a boot-loader for automotive ECUs, which have a CAN connection.
The relevant protocols, which provide the services, are ISO 14229-3 or SAE J1939/73, with the first one much more common to my experience.
For development purposes, also ASAM MCD-1 XCP has support for that.
However, these are just the communication services and does not include usual usage patterns, which differ a lot across the OEMs.
For security, the German OEMs put a document together called "HIS Security. Module Specification", which I unfortunately did not find any more on the web.
They also have a blueprint for the design of a boot-loader.
However, this is anyway somewhat outdated, as boot-loaders today often are at least partially based on AUTOSAR, like the applications.
Last from them, you could also get a document partially specifying how the services above are used for flashing an ECU.
If you need further input, feel free to ask.
However, you will need yourself access to the non-free industry standards and recommendations.
I have a project that requires ABAC for access control for my projects resources. I've been looking at OPA and authzforce as options to implement ABAC and OPA looks like it might be less complicated than authzforce. I see that OPA compares itself to other systems and paradigms but the example it gave for ABAC leaves a lot to be desired. Mainly because ABAC requires the use of points that enforce policies, makes decisions around policies, fetch subject and object attributes for policy decisions. I feel like OPA has everything but the last part covered but it's hard to tell if that's true since their ABAC example is just a one-off.
I've been looking all over the internet for examples of OPA being used as an implementation for ABAC but I haven't found anything.
My project is a web app that allows end-users to create resources and create policies for their resources. I plan to create a UI for the end-users to create their policies. my plan is to abstract away the coding aspect of it and instead, give them dropdowns and buttons this UI will use a custom syntax behind the scenes that I will interpret into an OPA policy.
The main issue I'm having is how to implement this as ABAC, is it as straight forward as building the part that will fetch the attributes for the subject, object, and environment and create the glue between it and OPA (essentially creating a PIP) since OPA itself appears to be a defacto PEP and PDP?
I feel like I'm drowning in the documentation and there seems to be quite a bit missing from OPAs own docs to explain how this can be done.
OPA looks like it might be less complicated than authzforce
There are a couple pros and cons to either approach. First of all, as you realized both OPA and AuthZForce are ABAC implementations (you can read more on ABAC here and here).
OPA
Open Policy Agent is a relatively novel model aimed mainly (but not only) at tackling fine-grained authorization for infrastructure (e.g. Kubernetes). They even have pre-built integration points for Istio and Kubernetes. OPA provides a PEP (enforcement / integration) and a PDP (policy decision point) though it does not necessarily call them that way. The language it uses is called REGO (a derivative of DATALOG).
OPA itself appears to be a defacto PEP and PDP
Yes you are absolutely right and that puts the burden on you to implement an alternative for PIPs.
I feel like I'm drowning in the documentation and there seems to be quite a bit missing from OPAs own docs to explain how this can be done.
Reach out to Styra - they sell services around OPA. Alternatively reconsider your choice and look into XACML (see below).
Drawbacks
the language (REGO) is not easy to understand
the language is not standardized
OPA does not support Policy Information Points (PIP) - that's by design.
Implementations
I've been looking all over the internet for examples of OPA being used as an implementation for ABAC but I haven't found anything.
Have a look at the work they did at Netflix. That's the main implementation I am aware of. You can also reach out to Styra, the company behind OPA, and they'll be able to help out.
AuthZForce
AuthZForce is an open-source Java implementation of the XACML (eXtensible Access Control Markup Language xacml) standard. It provides a full ABAC implementation (PAP, PEP, PDP, PIP). It's part of Fiware (an open source initiative) and it's actively developed by a team at Thales.
AuthZForce Drawbacks
it does not seem to have a graphical interface to author policies. I found a reference to KEYROCK PAP but couldn't see any screenshot
it does not support ALFA, the abbreviated language for authorization.
Implementations
There are many other implementations of XACML you can consider (both open-source and commercial):
AT&T XACML
SunXACML
WSO2 - part of their WSO2 Identity Server platform - it's called Balana
Axiomatics (commercial - this is where I work) - we have a large customer base using our platform ranging from Fortune 50 companies to agile startups.
Benefits of XACML & ALFA
One of the key benefits of XACML / ALFA is that they are standards and widely adopted. The standard has been around since 2001 and interoperates with other standards e.g. SAML, OAuth, and SCIM.
Perhaps the most concrete answer is a detailed description of how Chef Automate uses OPA to implement application authorization.
More generally, we are planning a guide describing how to use OPA for application authorization--it requires more detail than a SO answer. But using OPA (or any policy engine) for application authorization depends a bit on your application, its architecture, your SLAs, etc. But here are a few key issues to consider:
Policy: how much expressiveness do your end-user policies need? Do they just define say user-attributes or user-roles, or do they map user attributes/roles to permissions too? OPA lets you solicit those end-user policies as JSON objects and then write policy rules that make decisions using those JSON objects. And for efficiency, you can compile those JSON objects into bona-fide OPA rules.
Enforcement: where do you need to enforce authorization policies (e.g. gateway, microservice, database)? Your requirements around latency, size of data, expressiveness of database query languages will all impact this decision. OPA is flexible enough to help with all of these and has a couple of specific integrations that will help: Envoy and similar service-mesh systems for microservices and SQL/ElasticSearch for databases.
Data: how much attribute data is there, how frequently does it change, what consistency guarantees do you need, what mechanisms do you have for getting the data into OPA (e.g. caches, event-streams). Here's a guide for injecting data into OPA; it uses LDAP/AD as an example data-source, but the principles are the same for any data-source.
We are always happy to talk through the details of your application and help you find the right fit for OPA. Feel free to reach out on the OPA slack channel.
I'm wondering about additional complexities involved in integrating with Auth0 vs plenty of available code for password complexity rules, UI etc. including using snowflake starter app, for authentication/user creation with open source parse server.
I am sure plenty of people have thought about this and was wondering what the consensus is? Requirement to keep profile/email in sync, relying on 3rd party, inability to customize view and I am sure many other issues.
At first I thought this is great, I would not need to worry about a lot of things, yet there are a lot of other things to worry about and not being able to customize.
What are the most convincing "PRO" answers?
Disclosure: I'm an Auth0 engineer.
TL;DR: I can talk about the pros and cons, but the definitive answer needs to be provided by you.
A bit about Auth0
Auth0 supports the authentication protocols in most widespread use (OAuth2/OIDC, SAML and WS-Federation) so integration into custom software that speaks or can be made to speak by available libraries is relatively easy and friction free. Sidenote, Parse Server does seem to support integration with OAuth compliant identity providers.
It can be used as a standalone identity provider where your users register and authenticate with username/password credentials specific to your application, but it can also integrate with a lot of downstream identity providers like for example Google, GitHub and Twitter. This makes it really easy to enable different methods of authenticating users just by configuration instead of having to directly talk to each individual provider and have to deal with their implementation discrepancies.
Finally, it provides enough extensibility points for you to still have significant degree of control on the authentication experience, for example:
Rules (JS code) allow you to customize the authentication process
Customization of Auth0 provided authentication user interface allows you to still have your own branding
Customization of Lock allows you to have a custom authentication experience integrated in your own app really quick and with very little effort
Of course, no matter how many extension points there's always some stuff that you will not be able to control. This can be seen as bad, but sometimes it's actually a good thing. Depends on the perspective and your specific requirements.
Comparison - Roll your own (RYO) vs Third-party service
On one side you'll have:
cost of acquisition of the service
cost of integration of the service with your product
On the other side you'll have:
cost of implementing the features you need
cost of ownership of those features
cost of integration of the new features in your product
In both cases you'll need some integration work in order to make all the parts fit no matter who created the parts. You could argue that if you are the author of everything it will be easier to fit a square peg in a round hole so lets say RYO wins by a small margin on that point.
It then all comes to comparing cost of acquisition versus the cost of implementation and ownership. I can't answer that one, but the cost of acquisition is generally easy to calculate while the cost of implementing software is very hard to predict; on top of that owning a custom authentication solution also has a heavy toll... you know what they say, no one ever got fired by buying IBM. I won't go that further, but it's safe to say it's easier to find yourself in a pickle if you roll your own security. :)
Conclusions
Go through the Auth0 trial, play with it and see what it has to offer and how that matches your requirements.
If you find something you're not able to accomplish leave a question here tagged auth0 or on Auth0 Forums.
for a proof of concept i want to store rights. I know there are different ways of access control (DAC, MAC, RBAC,..). My first idea was using a database, but I'm looking for some more etablished standards like XACML but unfortunately I have not been able to find some real alternatives.
thanks for any tipps!
First, take a step back and look at comparable items.
In access control you have different models that have come up with time. Historically you first had DAC and MAC. You had the notion of access control lists (also known as identity-based access control or IBAC).
Then suddenly, the sole identity of a user was no longer enough. We started to organize users into roles and groups. That led to the creation of RBAC or role-based access control which NIST formalized into a standard.
Fast forward 10+ years and roles are not enough anymore. ACLs and RBAC are too user-centric. They do not cater for context or relationships. They are not fine-grained enough. A new model called ABAC or attribute-based access control emerges. NIST is also in the process of standardizing ABAC. ABAC is capable of implementing any type of access control requirement and can cater for user, resource, action, and context attributes.
You can read more on ABAC here.
So, what about XACML? XACML - the eXtensible Access Control Markup Language - is an implementation of the ABAC model. It is the most widely spread implementation of ABAC. You ask whether there are alternatives. Some that come to mind include:
SecPal: this is (was?) a Microsoft research initiative. To the best of my knowledge, it is not used outside research.
Permis is a policy-based access control model. It is not widely spread either.
Microsoft has its own language for Windows Server called SDDL. You can read more on that from Microsoft.
IN practice though, most ABAC implementations I have seen use XACML or a mix of home-grown code + RBAC. Needless to say, the latter doesn't really scale well and is hard to maintain.
If you want to learn more, check out the following resources:
my own personal blog
my personal SlideShare
We need to implement authorization rules like below.
If user is a Super Admin, then give him all customers information. like order information.
If user is a Customer Admin, only provide him own customer information. Etc.
We are planning to implement the filtration at DAO layer.
What could suggestion for creating a generic design to handle this scenario ? Assume that our application already has a DB model for RBAC(role based authorization control). We are open for any DAO technology, like JPA or iBATIS or native queries etc.
Highlevel acceptance criteria is Authorization policies should be configurable and can be changed at runtime.
Example: If Customer admin can see self data, in future rule can be changed to allow them to see self and friends data.
We evaluated authorization policy like XACML, did not like to implement it because of its complexity. We are planning to write a home-grown solution. Any suggestion, please welcome.
You write in your answer that you looked at XACML and did not implement it. What you should do is take XACML off-the-shelf either a vendor or an open-source alternative. You will find plenty in either category such as WSO2 (open source) or Axiomatics (vendor).
XACML is the de-factor standard for fine-grained attribute-based access control (see NIST's page on the topic). It's 10 years old and it's got the likes of IBM, Microsoft, Oracle, Axiomatics, and Bank of America behind it. With all due respect I very much doubt a home-grown solution will do.
You are looking for filtering at the DAO layer. It looks like you could use the Data Access Filter. It is XACML-based and you do not need to implement anything specific (read: developer effort is very low).
I cannot force you to go one way or another but I would seriously consider going standards-based. Any other way may sound like a good idea in the short term but it will bite back seriously in the medium to long term.