← Prev in month ← Prev in thread

PrimeLife attribute predicates: the simple case

From
Gregory Neven <>
Date
2010-11-25T09:28:31+00:00
ID
Thread
PrimeLife attribute predicates: the simple case
Dear all,

    

    As promised during last confcall, please find below a summary of the
    impact of attribute predicate assertions on XACML for the simple
    solution we had in mind. All discussion is welcome, in particular
    about the questions at the end of the email.

    

    Best regards,

    Greg

    

    General Principle
    

    

    
      
The policy is specified in terms of dedicated, only locally
        meaningful, boolean attributes.

      

      
Some component (PEP, PIP, or Context Handler -- see discussion
        below) knows the mapping from local attributeIDs to predicates
        over globally meaningful attributeIDs.

        e.g., urn:mypolicy:underage -> urn:unitednations:birthdate
        < 1992/11/09

      
When a local attribute is found missing, a SAML assertion
        request is generated for the corresponding predicate (either
        from the requestor, or directly from the IDP/issuer).

      
When a SAML assertion for the predicate comes in, the
        following checks are performed: 

      

      
        
Does the signature support the predicate in the assertion?

        
Is the predicate in the assertion "the same" as the
          predicate in the request. The easiest is probably to test by
          string equality after canonicalization.

        

      
    
    About the choice of which component should do the mapping local
    attributeIDs -> predicates:

    
      
PEP: Best placed if missing attributes are reported through
        status detail in an Indeterminate response, as described in
        XACML 2.0 spec section 7.15.3. It can then intercept
        Indeterminate responses with missing attributes, call out to the
        user/IDP with an assertion request for the corresponding
        predicate, verify the incoming SAML assertion, and generate a
        new XACML request context with the local attribute set to true.

      

      
PIP: Best placed if the PDP actively queries missing
        attributes from the PIP. What is the format of the communication
        between PDP and PIP for attribute  queries and responses,
        however? Is it standardized?

      
Context Handler: Is well placed in the sense that both missing
        attribute fetching mechanisms (via Indeterminate response or via
        PIP) pass through the Context Handler, but is poorly placed in
        the sense that it takes an XACML request context as input. If
        the Context Handler is responsible for handling incoming SAML
        assertions, then the schema of the XACML request context needs
        to be changed so that it can carry SAML assertions, rather than
        just attribute values.

      

    
    The main advantage of this simple approach is that the impact on
    XACML schema/architecture is minimal. The main disadvantage is that
    it puts the burden on the policy author to define the static mapping
    between local attributes and predicates over global attributes.

    Example

    
    XACML policy:

    

        <Rule Effect="Permit" RuleId="#rule1">

            <Target>  ... </Target>

            <Condition>

                <Apply
FunctionId="urn:oasis:names:tc:xacml:1.0:function:boolean-one-and-only">

                    <SubjectAttributeDesignator
    AttributeId="urn:mypolicy:local:isoverage" Issuer="http://www.trustedidp.com"
    DataType="http://www.w3.org/2001/XMLSchema#boolean"
    MustBePresent="true"/>

                </Apply>

            </Condition>

        </Rule>

    

    The PEP/PIP/Context Handler knows that urn:mypolicy:local:isoverage
    corresponds to a predicate:

    

                <Apply
FunctionId="urn:oasis:names:tc:xacml:1.0:function:date-less-than">

                    <Apply
FunctionId="urn:oasis:names:tc:xacml:1.0:function:date-one-and-only">

                        <SubjectAttributeDesignator AttributeId="http://www.w3.org/2006/vcard/ns#bday"
    Issuer="http://www.trustedidp.com"
    DataType="http://www.w3.org/2001/XMLSchema#date"/>

                    </Apply>

                    <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#date">1992-01-01</AttributeValue>

                </Apply>

    

    When no value for urn:mypolicy:local:isoverage is known at the time
    the rule is evaluated, then an "Indeterminate" decision is returned
    with status code
    "urn:oasis:names:tc:xacml:1.0:status:missing-attribute" (as per
    Section 7.15.3) listing urn:mypolicy:local:isoverage in the
    <MissingAttributeDetail> element. If the PEP/PIP/Context
    Handler obtains an assertion by trustedidp.com that the above
    predicate is true (by contacting either the requestor or the IDP
    directly), then a refined request context is resubmitted specifying
    that urn:mypolicy:local:isoverage is true:

    

    <Request>

        ...

        <Subject>

            <Attribute AttributeId="urn:mypolicy:local:isoverage"
    Issuer="http://www.trustedidp.com"
    DataType="http://www.w3.org/2001/XMLSchema#boolean">

                <AttributeValue>true</AttributeValue>

            </Attribute>

            ...

        </Subject>

    </Request>

    

    Questions
    
      
The XACML spec seems to specify two ways in which missing
        attributes can be treated, either by returning an Indeterminate
        response as per XACML 2.0 spec section 7.15.3, or call out to
        the PIP (via the Context Handler). Which mechanism is used when?
        Is the communication format for the latter mechanism
        standardized? 

      

      
How to distinguish local boolean attribute IDs that are in
        fact aliases for predicates over global attribute IDs from
        normal local attribute IDs? Should one standardize a URN prefix
        for these type of attributes, as Hal suggested?

      
The above flow assumes that, when missing attributes are
        encountered, an Indeterminate response is generated and a new
        request is resubmitted. I understand there is also an
        interactive way of fetching missing attributes, but I must admit
        that I don't understand where in the standard this mechanism is
        specified.

      

      
It would be nice if the predicate could contain environment
        attributes, such as the current date. For example, the above
        predicate could specify that "bday < today - 18Y" instead of
        "bday < 1992/01/01":

        

                    <Apply
FunctionId="urn:oasis:names:tc:xacml:1.0:function:date-less-than">

                        <Apply
FunctionId="urn:oasis:names:tc:xacml:1.0:function:date-one-and-only">

                            <SubjectAttributeDesignator AttributeId="http://www.w3.org/2006/vcard/ns#bday"
        Issuer="http://www.trustedidp.com"
        DataType="http://www.w3.org/2001/XMLSchema#date"/>

                        </Apply>

                            <Apply
FunctionId="urn:oasis:names:tc:xacml:1.0:function:date-subtract-yearMonthDuration">

                                <EnvironmentAttributeDesignator
        AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-date"

        DataType="http://www.w3.org/2001/XMLSchema#date"
        />

                                <AttributeValue DataType="http://www.w3.org/TR/2002/WD-xquery-operators-20020816#yearMonthDuration">P18Y</AttributeValue>

                        </Apply>

                    </Apply>

        

        Which predicate assertion would then be requested from the
        user/IDP however, the literal predicate above, or a "partially
        evaluated" predicate where the
        <EnvironmentAttributeDesignator> element is replaced with
        an <AttributeValue> element with the correct value? If the
        latter, who does the partial evaluation?
← Prev in month ← Prev in thread