Az FAQ
From OpenLiberty.org Wiki
Contents |
Foundations
1. What is the OpenAz project?
OpenAz is an open source project to build components for developers and deployers to use when implementing access control for applications and software infrastructure. The project is based on foundations given by the XACML standard, and builds on the model of deferring access control decisions to a policy engine.
More information can be found at:
http://www.openliberty.org/wiki/index.php/Main_Page#OpenAz
2. What is access control?
[RFC4949] A process by which use of system resources is regulated according to a security policy and is permitted only by authorized entities (users, programs, processes, or other systems) according to that policy.
3. What is authorization?
[XACML 2.0] Authorization is the process of determining if a request for access to a resource should be permitted together with enforcing that decision.
4. What is XACML and how can I learn more about it?
XACML is an Open Standard that defines a language for expressing and evaluating access control policies. Information on the Standard can be found here:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml
5. What is the Java AzApi?
AzApi is a Java programming interface to request authorization decisions. It is based on the language-independent definitions given by XACML for an authorization decision request and response.
6. Does the AzApi require use of a XACML policy engine or policy decision point?
No, it does not require the use of a policy engine based upon the XACML policy language. It only requires that the policy engine create authorization request and response messages using the definitions given in XACML.
7. Why do we need a new authorization API?
XACML defines an optional, abstract XML-based API and a network protocol for remote authorization decision requests, but has not yet defined a programmatic interface. Other existing authorization APIs are not capable of conveying all the inputs and outputs that XACML makes use of.
The XACML community participated in several interoperability events , during which it was found that vendors were defining similar but distinct APIs for authorization based upon XACML. This backstory motivated the creation of the AzApi as a single interface which could be implemented by many different products.
8. What languages are supported?
At the current time AzApi is defined as a Java Interface. The intention is to support a variety of other language environments, including .Net and legacy C/C++ as well as popular scripting languages.
9. Can this work with my favorite “------“ framework or language?
We encourage you to join the OpenAz project and help make this happen. We are interested in creating “bindings” that make AzApi useable in a appropriate way from various contexts.
10. I am interested in participating, how can I contribute to this project?
You can join the mailing list for discussion about the software at: http://lists.openliberty.org/mailman/listinfo/openaz_lists.openliberty.org
If you plan to contribute software, please fill out the Contributor License Agreement available at: http://www.openliberty.org/blog/licensing/
11. I am interested in using the software, which open source license are you using?
All contributions to OpenAz are licensed using the Apache 2.0 model as explained at: http://www.openliberty.org/licensing
Authorization
12. Can I use the AzApi to find out what a user’s attributes are?
No, AzApi provides user and other types of attributes to an authorization decision system. However, generally these attributes must first be obtained from an authoritative source using standards such as LDAP, SQL, SAML, WS-Trust or CARML.
13. Can I use the AzApi to authenticate a user?
No, information about when and how a user authenticated may be supplied as a part of the inputs to AzApi, but it must be obtained by other means.
14. Does the AzApi enforce access control?
No, it merely makes authorization decisions based on the inputs provided and the currently valid policies.
15. Where does it fit in the XACML Az architecture?
AzApi corresponds to the interface between Policy Enforcement Point (PEP) and a Policy Decision Point (PDP).
16. Do developers creating business applications need to understand the AzApi?
It is intended that in most cases, AzAPI will be called by software infrastructure components, such as an application server container or code automatically generated within an IDE. In rare cases, applications may need to use parts of the API to provide application-specific attributes not available elsewhere. Applications may also need to provide logic to process Obligations or Advice, if these are used.
17. Does XACML support claims-based Authorization?
Claims are properties of users. Claims-based Authorization can operate in a couple of different ways. Where claims represent simple attributes of users, it is simply standard XACML Authorization based on Attributes by a different name.
In some cases, Claims may actually be mini policy statements issued to a user which define what the user may do. XACML can support this mode in three ways. First a policy is required to determine what claims to issue. Second, XACML can be used at a way to express the Claims as an alternative to the Simple Claims Dialect defined in WS-Federation. Third, policy may still be required to determine how to apply the Claims in deciding if access should be allowed.
AzApi
18. What about JSR-115/JAAC in the J2EE platform?
JAAC is not capable of conveying all the inputs and outputs associated with the XACML authorization model. JAAC also does not provide a mechanism for returning Obligations (and in XACML 3.0 Advice). Further if a new type of Resource is to be protected, a new permission class must be implemented, requiring the application to be recompiled. Thus the use of XACML via JAAC may restrict its capabilities.
19. What versions of XACML can it be used with?
AzApi will work with any version of XACML (2.0, 1.1 or 1.0 and in future XACML 3.0)
20. Is the AzApi a standard?
The Java version of AzApi has been submitted to the OASIS XACML TC for standardization. The OpenAz Project will develop to produce open source code that implements AzApi for various purposes. As APIs are developed for other languages, the intention is to do the same.
21. Who is developing/implementing the AzApi?
Oracle and Cisco contributed the AzApi and AMF specifications to the OASIS XACML TC. Several other organizations are in the process of joining this effort.
22. Why is the AzApi so complicated?
XACML allows virtually any type of information (attributes) to be used as input to an authorization decision. The API must be able to convey this information; otherwise the functionality of the authorization decision system will be constrained. Further, the XACML model allows the authorization system to respond with Obligations, these improve the granularity and flexibility of access control.
23. How can it be made easier to use?
AzApi will be implemented by infrastructure software, thus making its use invisible to most applications. We also envisage the creation of “bindings” that are specific to particular frameworks and provide simplified interfaces for the access control problems of interest in these frameworks. Restricting to the common cases makes for an easier to use API, but one that will be limited in functionality.
24. Doesn’t XACML already define a standard request-response protocol?
Yes, but it does not currently define a programming language API.
25. How does the AzApi relate to the XACML SAML profile?
The XACML SAML Profile defines a number of distinct types of functionality. The most widely implemented component is the network protocol to request an authorization decision from a remote server. AzApi can be used to call a local authorization decision system or to make it easier to implement the remote protocol.
26. Will the AzApi work with a remote policy engine or policy decision point?
The OpenAz project intends to implement a client side proxy for this that will be callable via AzApi.
27. Will the AzApi work with an embedded policy engine located with the application?
AzApi is intended to support this type of usage with very high efficiency.
28. Does use of the AzApi require the use of XML when making authorization decisions?
AzApi represents data in native formats, not XML. There is no requirement that an authorization decision request or response involve the use of XML at any point in the processing cycle.
Attribute Manifest Format (AMF)
29. What is the Attribute Manifest Format?
AMF is an XML format for representing information about attributes that may be used in authorization decisions.
30. Why is AMF needed?
In modern access control systems, like XACML, only the Policy Decision Point (PDP) knows how to evaluate polices and which policies are currently in effect. However, the PDP must be provided with named attribute values in order to make authorization decisions. The AMF provides a way to communicate name, type and location information about these attributes.
31. How will AMF files be created?
It is expected that they will be generated n a variety of ways. In addition, to manual entry, AMF files may be generated by scanning user attribute repositories and databases, container configuration, existing polices, program declarations and document repositories.
32. How will AMF files be used?
Policy creation tools may use the type information to assist policy editing. Deployment tools can use AMF to reason about available versus required attributes, and to provision Policy Information Points (PIP) appropriately. Finally, PIPs may use AMF to locate attribute values for inclusion in an authorization decision request.
