How PIP and whole ABAC engine should behave in case if it can't resolve attributes.
There are several cases:
Destination object using which we are resolving attribute is not found
Attribute can't be resolve because provided attributes not sufficient to request addition information. Like if we passed single userId and resource name without id.
If during attributes resolution chain (when some attributes depends from another) something has been missing that make target attribute resolution impossible.
ABAC is a broad concept that does not specify this kind of low-level behavior; and it is difficult to give a universal best practice for all ABAC frameworks, since there is a growing bunch of them possibly quite different: some of them are standard (eg. OASIS XACML, NIST NGAC), others non-standard yet generic (eg. OPA), others product-specific (eg. Kubernetes ABAC).
It is easier to give tips for the XACML (3.0) standard since the specification is more mature:
§ 5.29 says: In the event that no matching attribute is present in the context, the MustBePresent attribute governs whether this element returns an empty bag or “Indeterminate”. See Section 7.3.5. (The MustBePresent is defined on AttributeDesignator elements in your XACML Policy. An AttributeDesignator is a reference to an attribute, for which, in your case, a PIP should be called if the attribute is not available in the current request context.)
§ 7.3.5 gives more details: If the attribute is missing, then MustBePresent governs whether the attribute designator or attribute selector returns an empty bag or an “Indeterminate” result. If MustBePresent is “False” (default value), then a missing attribute SHALL result in an empty bag. If MustBePresent is “True”, then a missing attribute SHALL result in “Indeterminate”. This “Indeterminate” result SHALL be handled in accordance with the specification of the encompassing expressions, rules, policies and policy sets. If the result is “Indeterminate”, then the AttributeId, DataType and Issuer of the attribute MAY be listed in the authorization decision as described in Section 7.17. However, a PDP MAY choose not to return such information for security reasons. [...] 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.) The last sentence means in particular that if PIP attribute resolution results in an empty bag and MustBePresent=False, you should keep the attribute value as empty bag for the rest of the policy evaluation, i.e. NOT try to call the PIP again for the same attribute (risking a value change) in the same context.
§ 7.19.3 specifies how the PDP should include the information about a missing attribute in its response.
Beware that the final result is also affected by combining algorithms in XACML. E.g. even if an AttributeDesignator returns Indeterminate because of a PIP error in a child Rule/Policy(Set), algorithms of the enclosing policy like deny-unless-permit (resp. permit-unless-deny) may return Deny (resp. Permit) regardless.
That's what the standard says, then, there is implementation-specific behavior. In AuthzForce XACML implementation for instance, we distinguish the following cases while trying to be as XACML compliant as possible:
If PIP internal error occurs during attribute resolution (connection issues, misconfiguration, missing dependency, etc.), then the AttributeDesignator evaluates to Indeterminate regardless of MustBePresent, because we consider this critical, and we add the info Missing attribute XXX; we also add info about the cause, e.g. Missing dependency: attribute YYY if PIP requires some attribute that was missing from the context to do its job (e.g. missing dependency: attribute 'subject-id' if the PIP fetches the user's roles but requires the subject-id attribute to do that, which is missing).
If PIP attribute resolution is done error-free but no value found, in other terms the result is empty (e.g. some PIP fetches the user's roles successfuly from a database but gets an empty list because no role has been assigned to the user.), then the AttributeDesignator evaluates to an empty bag if MustBePresent=false, else (if MustBePresent=true) returns Indeterminate with the info Missing attribute XXX.
The interaction between the PDP and the PIP is not specified in the XACML standard. It is down to each implementation (AuthZForce, Axiomatics...) to determine how they handle each case.
Generally speaking, there are 3 errors that can occur when using a PIP:
Connection issues: the target PIP (e.g. an LDAP server) cannot be reached
Mapping configuration issues: the mapping for the attribute is invalid. For instance you are retrieving an attribute from a non-existing SQL table or column.
Data issue: there is no data to be read in the underlying source
In addition, there is another possible issue: the keys used in the mapping (e.g. username) has no value at all. In this case, it is clear that the mapping (e.g. to retrieve a role) will not be invoked at all.
Points 1 and 2 could lead to Indeterminate. This helps the administrator troubleshoot the installation.
Point 3 should lead to NotApplicable for that branch that uses the attribute. If there is no value, then so be it. Why would there necessarily be a value?
I hope this helps,
David.
Related
I am trying to understand which attributes are required and which are not.
As far as I understood you look at the corresponding IOD to your SOP class and then check which modules are mandatory or not. Then in the modules you can see which attributes are required and which are not.
For example if my SOP class is multi frame ultrasound images, I look at the corresponding IOD, which can be seen on this page:
https://dicom.nema.org/dicom/2013/output/chtml/part03/sect_A.7.html
Then I see a module called "Clinical Trial Subject", it's usage says U, which means it's optional. However when I check the module on this page, I see multiple attributes which are listed as type 1, which means these attributes are required.
I was wondering if I should add these attributes in the DICOM header or if I can ignore it because in the IOD it says this module is optional.
What this means is that the module itself is optional, but if you have the module then those elements are mandatory within the module.
This makes sense logically: obviously a single study may, or may not, be a clinical trial - hence the clinical trial module is optional.
However if a study is part of a clinical trial, then there are definitely some information you always want to know. So those elements within the trial module are mandatory.
I'm trying to add some forward compatibility to a Java application calling a Web Service at work, but JAXB seems to behave backward on the subject...
The application use the wsdl2java Maven plugin to generate a CXF Web Service client from a WSDL. It then uses that generated client to communicate with a Web Service (through SOAP over JMS).
When the Web Service sends an unknown element in its response to a call, JAXB fails with an "unexpected element" error, which is understandable, and XML-compliant. To be more forward compatible, I specified a custom jaxb-reader-validation-event-handler to ignore those specific errors, which solved the problem.
But while doing some complementary tests, I discovered non-XML-compliant behaviours.
First, JAXB doesn't care about elements' order, even inside a sequence, which is not XML-compliant, but good for forward compatibility, so why not.
However, it also doesn't care if a mandatory element (minOccurs="1") is not present, kindfully assigning it an arbitrary default value (which is, for elements bound to Java primitive values, their default values, like 0 for an int!).
This is both non-XML-compliant and not good for compatibility: if you need a mandatory, say, price as an integer, but the Web Service doesn't provide it for some reason, JAXB assigns the value 0 to it without a warning, making debugging really hard.
Apparently it's because if JAXB doesn't encounter an element, it simply doesn't call its setter, which means it will keep its default value.
[EDIT: I made some complementary tests, and when the application expect 1 element (maxOccurs="1") but the Web Service sends 2, JAXB calls the same setter two times, overriding the first value with the second, so it seems that once the client is generated from the WSDL, minOccurs and maxOccurs are simply ignored...]
How can I make JAXB to fail when a mandatory element is missing?
We noticed that, even for an element with minOccurs="1", the annotation of the corresponding generated attribute does not contain required = true. I tried to add it manually after the generation and before starting the application, but with no success: it seems it's simply ignored...
Maybe an additional JSR–303 validation covers what you want to achieve. You may either extend xjc’s behavior with a plugin like: https://github.com/krasa/krasa-jaxb-tools to have your binding classes annotated, or use Hibernate Validator in conjunction with XML validation config as described here: https://docs.jboss.org/hibernate/validator/4.1/reference/en-US/html/validator-xmlconfiguration.html#validator-xmlconfiguration
is there a default visibility in UML2 if I don't (want to) add one of the four reserved visibilities?
As I know there is + for public, - for private, # for protected and ~ for package.
Or is the default depend on the implementation language that should be used, e.g. package for Java or private for C++?
Thanks so far.
If you don't add it then it's a don't care. Languages itself have their own rules and UML does not know how a language will treat it. The same goes for tools. They place one of the symbols (either public or private) as default and you eventually can change a default to something else. But again UML does not care.
Depending on how you use it you can tell the reader that a missing symbol will mean this or that.
Edit 1: Thanks to #xmojmr digging into the UML spec and the great critic uml-diagrams.org here are two statements. OMG first (SS2.4.1):
7.3.38 Package (from Kernel)...The query makesVisible() defines whether a Package makes an element visible outside itself. Elements
with no visibility and elements with public visibility are made
visible" and "7.3.39 PackageableElement (from Kernel)...
visibility...Default value is public
and from http://www.uml-diagrams.org/property.html
Note, that there is no default visibility. Also, visibility may be suppressed from being displayed on a diagram, even if it has some value in the model (e.g. stored by UML tool). So, if visibility is not shown on a diagram, it was either not specified or suppressed
Please also note that my original statement was just an expression of my experience from using UML in the real world. Feels good to see that my experience seems to be in synch with the theories ;-)
Edit 2: Looking into the 2.5 specs I found this in chap. 7.8 Classifier Descriptions on p. 48:
Attributes
- visibility : VisibilityKind [0..1] = public
A PackageableElement must have a visibility specified if it is owned by a Namespace. The default visibility is public.
Constraints
- namespace_needs_visibility
A PackageableElement owned by a Namespace must have a visibility.
inv: visibility = null implies namespace = null
So it says the default is public. But the constraint says it must have a visibility. Which to me means that you need to specify it?
If you don't understand definition, read the definition for definition :-/
My XML files have restrictions on the child elements, but it really doesn't matter what the name of the root element is. How can I incorporate this into my XSD? I've tried using <xs:any> but I get:
"S4s-elt-invalid-content.1: The Content Of 'schema' Is Invalid. Element 'any' Is Invalid, Misplaced, Or Occurs Too Often."
So I tried missing the name off the element tag like this: <xs:element> but then I get:
"S4s-att-must-appear: Attribute 'name' Must Appear In Element 'element'."
Use a named type, and tell your validator to start validation at the root element using that type.
(There is one possible hitch with this: XSD 1.0 suggests that as one possible invocation option, but does not require validators to provide it, so there's no guarantee the validator interface you use will support it. Depends on your validator. Worth trying, at least.)
Another way to put this: you already have what you are asking for, because your XSD schema never cares what the root element of your document instance is called. An XSD schema provides a set of element and type declarations (among other things). A validator can be requested to start the validation at any point in the document, not just the root, and with either an element declaration or a type declaration, or in 'lax wildcard mode' (the most common default). If your validator doesn't offer the invocation options you want, it's a flaw in your choice of validator, not a gap in XSD.
I think I might just make the requirement stricter and insist on using a particular tag as the root element. The fact that the application doesn't care is not really a problem.
It seems (to me) strange that this limitation exists, but I am new to XSDs.
I am currently teaching myself RDFa Core 1.1 after successfully learning RDFa Lite rather easily. Straight to the point, I can't understand two things: the difference between property and rel, and the difference between resource and about.
Please explain to me in simpler terms than the spec :)
property vs. rel:
Both attributes indicate a predicate of a triple, e.g. rel="http://purl.org/dc/terms/creator, which is the predicate ... has as a creator: ....
The difference is, from where they take their object. Slightly simplified, the rules for property are: The object is taken ...
from a valid content attribute or, if this is not present in the tag,
(if no datatype attr is present in the tag:) from a valid resource attribute or, if this is not present in the tag,
(if no datatype attr is present in the tag:) from a valid href attribute or, if this is not present in the tag,
(if no datatype attr is present in the tag:) from a valid src attribute or, if this is not present in the tag,
from the inner content of the element started by the tag.
Slightly simplified, rel differs in two aspects:
It takes its object only from a resource or a href or a src attribute.
It takes its object not only from an attribute of the same tag, but may also take it from descendant tags. The whole mechanism is called "chaining": "This is the main difference between #property and #rel: the latter induces chaining, whereas the former, usually, does not." 1 Usually, but property can induce chaining if used with typeof (cf. 2).
about vs resource:
about is the attribute to indicate the subject of a triple. The rules for resource are more complicated: It may indicate a subject or an object, and chaining plays a role here, too.
IMHO, chaining is the most complicated and confusing part of RDFa (and does not give you more than syntactic sugar). I would avoid chaining. This is possible by avoiding the attributes rel, rev, resource and typeof, which brings some further simplification at the same time. Thus, I use only the following attributes:
about for the subject
property for the predicate
content or href or src (or the inner content of the element) for the object, following the rules outlined above
lang for a language tag for object literals, e.g. lang="en"
datatype for a datatype tag for object literals
prefix (but only once in a document), so that I can abbreviate URLs by prefixing, e.g. property="dc:creator"
vocab (rarely and at the most once in a document), so that I can abbreviate URLs implicitly, e.g. property="creator".
(And I use the tag <base href="..."> to indicate the URL base value of the document.)
This is a strict, safe, easy-to-use and easy-to-parse subset of RDFa and allows to express any triple you want.
I would personally recommend to ignore / avoid using rel and about, they are not really necessary to write RDFa if you follow the rule of thumb that you should not try to be too smart by stuffing as many attributes as possible in a given HTML element. There are around for backward compatibility reasons. The other attributes from 1.1 are worth learning though: content and datatype.
Stephan's advice is in general conformance with RDF Lite 1.1, which does not include #rel or #about for precisely these reasons.
Another good rule of thumb is to not try to include markup of more than one entity on a given element, which was often an example of specifying an images license.
#property and #rel are very similar to each others, but served different purposes in RDFa 1.0, but this was confusing, even for experts. (Formerly, #rel was used for specifying objects which are other nodes, and #property was used for specifying literal values. While there are some remaining differences, but sticking to non-clever markup, you can do everything with #property that you could do with #rel.
Similarly, #about can be avoided to just use #resource. The difference is that #about sets the current subject and #resource the current object, but for child nodes the parent object (taken from the parent's current object becomes the current subject. There were another minor differences concerning the presence of #typeof, but if you only use #resource, it pretty much does what you want.
To summarize the best practices from RDFa Lite 1.1 you can also check out the RDFa 1.1 Primer:
stick to #vocab, #prefix, #property, #resource, and #typeof
avoid making more than one statement in a given element