OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only
  • 1.  SAML & XACML for Trust Elevation

    Posted 09-18-2015 01:16
      |   view attached
    Hello, Attached and below are the additions I've made so far for the Trust Elevation document.  Suggestions welcome. 4.3.3 XACML Authorization Model The eXtensible Access Control Markup Language (XACML) standard defines a reference architecture for Attribute-Based Access Control (ABAC), a language for expressing access control rules and policies, and a protocol for generating and processing access control requests and returning responses.   Access to resources is mediated by a Policy Enforcement Point (PEP), which relies on decisions from a Policy Decision Point (PDP).  When a user attempts to access a protected resource, the PEP assembles a request, which provides attributes about the user, the resource, the environment, and the action requested.  The PEP communicates the request to the PDP, which evaluates it according to pre-defined policies.   To perform Trust Elevation, the access control policy can specify how users must be authenticated, including parameters such as authentication method, credentials accepted, and levels of assurance.  Consider the following example:  a user requests access to a protected resource.  The access control policy governing the resource requires multi-factor authentication using a strongly vetted identity credential by means of setting the MustBePresent attribute to TRUE.  The PEP controlling access to the resource has only hitherto validated the user identity by means of a lower assurance username/password combination.  When the PEP initially formulates the request, it bases the user identity attribute on the previous username/password authentication event.  When the PDP receives the request, it evaluates the request according to the appropriate policy, based on the resource.  Since MustBePresent = TRUE, the PDP renders an “Indeterminate” decision, with a status code of “urn:oasis:names:tc:xacml:1.0:status:missing-attribute”.  Upon receiving this “Indeterminate” with MissingAttribute status decision, the PEP may resubmit a request after acquiring the proper attributes.  In this case, the proper attributes could only be gathered through a step-up authentication event.  This sequence constitutes a sample Trust Elevation event. 4.3.4 SAML Backend Attribute Exchange (BAE) Model The Security Assertion Markup Language (SAML) standard defines a means for representing authentication events between different trusting security domains.  A SAML assertion may contain a variety of attributes about the requesting subject and the conditions of the authentication event.  Subject and Issuer attributes generally relate the name of the subject and the name of the organization with which the subject is associated in the AuthenticationStatement element. The AuthenticationStatement also contains an AuthenticationContext attribute, which details how the subject was authenticated in the context of the current assertion. SAML-aware relying party applications can request additional attributes via the AttributeQuery element.  Moreover, SAML authorities can request full attribute evaluations via the AuthzDecisionQuery element.  Relying parties may specify acceptable authentication methods and credentials by using the RequestedAuthnContext element, and can force a fresh authentication event by setting ForceAuthn to true. Trust Elevation can be exemplified in the following scenario using SAML:  a user attempts to access content protected by a SAML-aware relying party (RP) application.  The user posts a SAML assertion containing Subject/Issuer attributes and indicates a low level assurance authentication event to the RP.  The RP’s access control policy requires additional attributes and a higher strength credential and authentication event.  The RP initiates a SAML authentication request to the user’s home domain.  This forces a step-up authentication event and retrieval of additional attributes, as required by the attribute contract.   Attachment: trust-el-protocol-v1.0-wd04c.docx Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document

    Attachment(s)



  • 2.  Re: [xacml] SAML & XACML for Trust Elevation

    Posted 09-20-2015 22:53
    Hi John, On 18/09/2015 11:15 AM, John Tolbert wrote: Hello, Attached and below are the additions I've made so far for the Trust Elevation document. Suggestions welcome. *4.3.3 XACML Authorization Model* The eXtensible Access Control Markup Language (XACML) standard defines a reference architecture for Attribute-Based Access Control (ABAC), a language for expressing access control rules and policies, and a protocol for generating and processing access control requests and returning responses. Access to resources is mediated by a Policy Enforcement Point (PEP), which relies on decisions from a Policy Decision Point (PDP). When a user attempts to access a protected resource, the PEP assembles a request, which provides attributes about the user, the resource, the environment, and the action requested. The PEP communicates the request to the PDP, which evaluates it according to pre-defined policies. To perform Trust Elevation, the access control policy can specify how users must be authenticated, including parameters such as authentication method, credentials accepted, and levels of assurance. Consider the following example: a user requests access to a protected resource. The access control policy governing the resource requires multi-factor authentication using a strongly vetted identity credential by means of setting the MustBePresent attribute to TRUE.The PEP controlling access to the resource has only hitherto validated the user identity by means of a lower assurance username/password combination. When the PEP initially formulates the request, it bases the user identity attribute on the previous username/password authentication event. So what would these attributes look like in practice ? subject-id-authenticated-by-password subject-id-authenticated-by-smart-card subject-id-authenticated-by-biometric-iris-scan subject-id-authenticated-by-biometric-fingerprint subject-id-authenticated-by-two-factors subject-id-authenticated-by-three-factors etc. > When the PDP receives the request, it evaluates the request according to the appropriate policy, based on the resource. Since MustBePresent = TRUE, the PDP renders an “Indeterminate” decision, with a status code of “urn:oasis:names:tc:xacml:1.0:status:missing-attribute”. Upon receiving this “Indeterminate” with MissingAttribute status decision, the PEP may resubmit a request after acquiring the proper attributes. In this case, the proper attributes could only be gathered through a step-up authentication event. This sequence constitutes a sample Trust Elevation event. There is a discrepancy between the description above, where the PEP initiates the step-up authentication, and the diagram in the attached draft profile where the PDP/context handler initiates the step-up authentication. Steven *4.3.4 SAML Backend Attribute Exchange (BAE) Model* The Security Assertion Markup Language (SAML) standard defines a means for representing authentication events between different trusting security domains. A SAML assertion may contain a variety of attributes about the requesting subject and the conditions of the authentication event. Subject and Issuer attributes generally relate the name of the subject and the name of the organization with which the subject is associated in the AuthenticationStatement element. The AuthenticationStatement also contains an AuthenticationContext attribute, which details how the subject was authenticated in the context of the current assertion. SAML-aware relying party applications can request additional attributes via the AttributeQuery element. Moreover, SAML authorities can request full attribute evaluations via the AuthzDecisionQuery element. Relying parties may specify acceptable authentication methods and credentials by using the RequestedAuthnContext element, and can force a fresh authentication event by setting ForceAuthn to true. Trust Elevation can be exemplified in the following scenario using SAML: a user attempts to access content protected by a SAML-aware relying party (RP) application. The user posts a SAML assertion containing Subject/Issuer attributes and indicates a low level assurance authentication event to the RP. The RP’s access control policy requires additional attributes and a higher strength credential and authentication event. The RP initiates a SAML authentication request to the user’s home domain. This forces a step-up authentication event and retrieval of additional attributes, as required by the attribute contract. --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


  • 3.  Re: [xacml] SAML & XACML for Trust Elevation

    Posted 09-21-2015 01:02
    John-- It might be helpful to clarify early on that "trust elevation" can mean either enhancing authentication, or enhancing authorization (more authZ attribs), or both. (Assuming I am interpreting your intent correctly) Martin On Sun, Sep 20, 2015 at 6:52 PM, Steven Legg < steven.legg@viewds.com > wrote: Hi John, On 18/09/2015 11:15 AM, John Tolbert wrote: Hello, Attached and below are the additions I've made so far for the Trust Elevation document.  Suggestions welcome. *4.3.3 XACML Authorization Model* The eXtensible Access Control Markup Language (XACML) standard defines a reference architecture for Attribute-Based Access Control (ABAC), a language for expressing access control rules and policies, and a protocol for generating and processing access control requests and returning responses. Access to resources is mediated by a Policy Enforcement Point (PEP), which relies on decisions from a Policy Decision Point (PDP).  When a user attempts to access a protected resource, the PEP assembles a request, which provides attributes about the user, the resource, the environment, and the action requested.  The PEP communicates the request to the PDP, which evaluates it according to pre-defined policies. To perform Trust Elevation, the access control policy can specify how users must be authenticated, including parameters such as authentication method, credentials accepted, and levels of assurance. Consider the following example:  a user requests access to a protected resource.  The access control policy governing the resource requires multi-factor authentication using a strongly vetted identity credential by means of setting the MustBePresent attribute to TRUE.The PEP controlling access to the resource has only hitherto validated the user identity by means of a lower assurance username/password combination.  When the PEP initially formulates the request, it bases the user identity attribute on the previous username/password authentication event. So what would these attributes look like in practice ?     subject-id-authenticated-by-password     subject-id-authenticated-by-smart-card     subject-id-authenticated-by-biometric-iris-scan     subject-id-authenticated-by-biometric-fingerprint     subject-id-authenticated-by-two-factors     subject-id-authenticated-by-three-factors     etc. > When the PDP receives the request, it evaluates the request according to the appropriate policy, based on the resource.  Since MustBePresent = TRUE, the PDP renders an “Indeterminate” decision, with a status code of “urn:oasis:names:tc:xacml:1.0:status:missing-attribute”.  Upon receiving this “Indeterminate” with MissingAttribute status decision, the PEP may resubmit a request after acquiring the proper attributes.  In this case, the proper attributes could only be gathered through a step-up authentication event.  This sequence constitutes a sample Trust Elevation event. There is a discrepancy between the description above, where the PEP initiates the step-up authentication, and the diagram in the attached draft profile where the PDP/context handler initiates the step-up authentication. Steven *4.3.4 SAML Backend Attribute Exchange (BAE) Model* The Security Assertion Markup Language (SAML) standard defines a means for representing authentication events between different trusting security domains.  A SAML assertion may contain a variety of attributes about the requesting subject and the conditions of the authentication event.  Subject and Issuer attributes generally relate the name of the subject and the name of the organization with which the subject is associated in the AuthenticationStatement element. The AuthenticationStatement also contains an AuthenticationContext attribute, which details how the subject was authenticated in the context of the current assertion. SAML-aware relying party applications can request additional attributes via the AttributeQuery element.  Moreover, SAML authorities can request full attribute evaluations via the AuthzDecisionQuery element.  Relying parties may specify acceptable authentication methods and credentials by using the RequestedAuthnContext element, and can force a fresh authentication event by setting ForceAuthn to true. Trust Elevation can be exemplified in the following scenario using SAML:  a user attempts to access content protected by a SAML-aware relying party (RP) application.  The user posts a SAML assertion containing Subject/Issuer attributes and indicates a low level assurance authentication event to the RP.  The RP’s access control policy requires additional attributes and a higher strength credential and authentication event.  The RP initiates a SAML authentication request to the user’s home domain.  This forces a step-up authentication event and retrieval of additional attributes, as required by the attribute contract. --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Martin F Smith, Principal BFC Consulting, LLC McLean, Va 22102 703 506-0159 703 389-3224 mobile