* Put attributes of a specific category in request.
*
* @param categoryName
* category URI
* @param categorySpecificAttributes
* attributes in category {@code categoryName}
* @throws java.lang.IllegalArgumentException
* if {@code categoryName == null || categorySpecificAttributes == null} or duplicate attribute category (this method was already called with same {@code categoryName})
thrownewIllegalArgumentException("Duplicate Attributes[@Category] in Individual Decision Request (not allowed): "+categoryName);
}
}
/*
* Convert growable (therefore mutable) bag of attribute values to immutable ones. Indeed, we must guarantee that attribute values remain constant during the evaluation of the request, as
* mandated by the XACML spec, section 7.3.5: <p> <i>
* "Regardless of any dynamic modifications of the request context during policy evaluation, the PDP SHALL behave as if each bag of attribute values is fully populated in the context before it is first tested, and is thereafter immutable during evaluation. (That is, every subsequent test of that attribute shall use the same bag of values that was initially tested.)"
* Parse Request attributes and group possibly repeated categories to implement Multiple Decision Profile, §2.3.
*/
/*
* We would like that the order of attributes (more particularly attribute categories) included in the result be in the same order as in the request (more particularly, attribute categories in
* order of first occurrence in the case of Multiple Decision Request); because "Clients generally appreciate having things returned in the same order they were presented." (See Java
* LinkedHashMap javadoc description.) Therefore, we use a LinkedHashMap for the Map<CategoryName,Attributes> below. If the impact on performance proves to be too negative, we might switch to
* a simpler Map implementation not preserving iteration order. Unfortunately, Koloboke - that we are using as HashMap alternative to JDK - does not support LinkedHashMap equivalent at the
* moment: https://github.com/leventov/Koloboke/issues/47 (we should keep an eye on it). So until this resolved, we use JDK LinkedHashMap.
* Generate the Multiple Individual Decision Requests starting with initialIndividualReq and cloning/adding new attributes/content for each new attribute category's Attributes alternative in
* requestAttrAlternativesByCategory
*/
/*
* XACML Multiple Decision Profile, § 2.3.3: "For each combination of repeated <Attributes> elements, one Individual Decision Request SHALL be created. This Individual Request SHALL be
* identical to the original request context with one exception: only one <Attributes> element of each repeated category SHALL be present."
* As explained at the beginning of the method, at this point, we want to make sure that entries are returned in the same order (of first occurrence in the case of Multiple Decision Request)
* as the categories in the request, where each category matches the key in the entry; because "Clients generally appreciate having things returned in the same order they were presented." So
* the map should guarantee that the iteration order is the same as insertion order used previously (e.g. LinkedHashMap).
* New newIndividualReqBuilders created below from this $oldIndividualReqBuilder will replace it in the list of $individualRequestBuilders (and will be used in their turn as
* $oldIndividualReqBuilders). So remove current $oldIndividualReqBuilder from the list
*/
individualRequestsIterator.remove();
/*
* Before we add the first category alternative (categoryAlternative0) to the oldReq already created (the "old" one), we clone it for every other alternative, then add this other
* alternative to the new clone. Note that we called categoryAlternatives.poll() before, removing the first alternative, so categoryAlternatives only contains the other alternatives
* XACML/JSON - according to XACML JSON Profile - Request preprocessor implementing Multiple Decision Profile, section 2.3 (repeated attribute categories). Other schemes are not supported.
* Factory for this type of request preprocessor that allows duplicate <Attribute> with same meta-data in the same <Attributes> element of a Request (complying with XACML 3.0 core
* spec, §7.3.3) but using JSON-Profile-defined format.
* Factory for this type of request preprocessor that does NOT allow duplicate <Attribute> with same meta-data in the same <Attributes> element of a Request (NOT complying fully with
* XACML 3.0 core spec, §7.3.3) but using JSON-Profile-defined format.
* Creates instance of default request preprocessor
*
* @param datatypeFactoryRegistry
* attribute datatype registry
* @param strictAttributeIssuerMatch
* true iff strict attribute Issuer match must be enforced (in particular request attributes with empty Issuer only match corresponding AttributeDesignators with empty Issuer)
* @param allowAttributeDuplicates
* true iff duplicate Attribute (with same metadata) elements in Request (for multi-valued attributes) must be allowed
* @param requireContentForXPath
* true iff Content elements must be parsed, else ignored
* @param extraPdpFeatures
* extra - not mandatory per XACML 3.0 core specification - features supported by the PDP engine. This preprocessor checks whether it is supported by the PDP before processing the
* Default XACML/JSON - according to XACML JSON Proifle - Request preprocessor for Individual Decision Requests only (no support of Multiple Decision Profile in particular)
* Default XACML/JSON - according to XACML JSON Profile - Request preprocessor for Individual Decision Requests only (no support of Multiple Decision Profile in particular)
