Profile LDAP

From OpenLiberty.org Wiki

Jump to: navigation, search

Contents

LDAP IGF Privacy Control

Revised: June 29, 2009

Project Index

Project Aristotle

Downloads

ArisID

ArisID Providers


Related External Information

Other

This is a draft specification for an LDAP Control to be used to support transmission of IGF information over LDAP Protocol. It is provided under the terms of the openLiberty Apache 2.0 License.

Introduction

This document defines the Lightweight Directory Access Protocol (LDAP) IGF Privacy Control. The Identity Governance Framework is a set of standards from the Liberty Alliance covering propagation of identity related information across common Internet protocols. The IGF Privacy Control extends the LDAP Protocol to allow the exchange of IGF metadata information between clients and servers.

In practice, this control is intended to used in combination with other LDAP Controls (e.g. the Proxy Authorization Control [RFC4370] to propagate additional transactional context information between clients and servers. For servers the additional IGF context information may be used in fine-grain access controls such as might be provided by a policy enforcement point (PEP) module implementing LDAP Access Control Requirements [RFC2820].

The IGF Privacy Control contains references to: application URI [RFC2396] identifiers, a [CARML] document URI, and declared transaction name identifier. Additionally, the privacy control also contains [WS-Policy] zero or more policy statements or policy references.

Background on IGF

The Identity Governance Framework [IGF] is about enabling the secure and appropriate exchange of identity-related information between users and applications and service providers (both internal and external) is the basis of providing deeper and richer functionality for services oriented architecture.

Sensitive identity-related data such as addresses, social security numbers, bank account numbers and employment details are increasingly the target of legal, regulatory and enterprise policy. These include,but are not limited to: the European Data Protection Initiative, Sarbanes-Oxley, and Gramm-Leach-Bliley as examples.

Publishing Support for the IGF Privacy Control

Support for the IGF Privacy Control is indicate by the presence of the Object Identifier (OID) "1.3.6.1.4.1.31052.1.1" in the supportedControl attribute [RFC2252] of a server's root DSA-specific entry (DSE).

Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

IGF Privacy Control

The IGF Privacy Control Contains the following information:

  • Control type
  • Criticality
  • The application name URI
  • The CARML Declaration URI
  • A transaction name identifier
  • A count of embedded WS-Policy Objects
  • Zero or more WS-Policy objects

A single IGF Privacy Control may be included in any search, compare, modify, add, or delete operation. (can it used for StartTLS, bind, modify DN???)

The control type of the IGF Privacy Control is "1.3.6.1.4.1.31052.1.1".

LDAP Control criticality MAY be present. For request side operations, server support is OPTIONAL in the case of LDAP SEARCH operations, but is REQUIRED for any operation transferring date to the server. The server will most often use the IGF Privacy information for the stated purpose of providing additional context that may be required in access control decisions. The mechanism for determining access rights is specific to the server's authorization policy. For response operations, criticality MUST be observed by the client (as the response control may contain privacy obligations from the server).

The controlValue is an OCTET STRING, whose value is the BER encoding of the following SEQUENCE: 

       controlValue ::= SEQUENCE {
          appName                 OCTET STRING,
          carmlUri                OCTET STRING,
          transId                 OCTET STRING,
          policy                  policySequence
       }

The appName is a value containing the application name URI.

The carmlUri is a value containing the URI of a CARML document describing an applications user of identity related information.

The transId is a value containing a transaction identifier from a CARML Document (referenced by carmlUri) for the transaction currently being performed.

The policy is an OCTET STRING, whose value is the BER encoding of the following SEQUENCE: 

      polStmt ::= OCTET STRING

      policySequence ::= SEQUENCE {
          policyCount     INTEGER (0..maxInt),
          policy1         polStmt,
          policy2         polStmt,
          ...
          policyCntValue  polStmt
       }

Editors Note: Should there only be one WS-Policy statement (which may contain more than one policy. Or is it important to have a sequence of policies that each could be tied to an attribute or the transaction itself? In the latter case, the number of policies would have to correspond to the number of attributes in the transaction + 1. See Extended PolicySequence Variation below.

The policySequence contains a policyCount INTEGER specifying the number of policy statements contained in the policySequence.

A polStmt is an OCTET STRING, whose value is a BER encoding of a WS-Policy. A WS-Policy is an XML String that MAY typically contain one or more IGF Privacy Constraints [PRIV-CON], or it may contain a [WS-Policy] reference containing a URI to a WS-Policy [WS- Policy Section 4.3.4].

Extended PolicySequence Variation

Note: The current ArisID PrivacyControl implementation follows this implementation.

The following allows for a set of policies each associated with a particular schema in a transaction. schemaId SHALL identifies the name of a schema element (attribute, role, predicate), or it MAY contain the value "TX" to identify transaction level policy. 

      policySequence ::= SEQUENCE {
          policyCount     INTEGER (0..maxInt),
          policy1         polStmt,
          policy2         polStmt,
          ...
          policyCntValue  polStmt
      }

      polStmt ::== SEQUENCE {
          schemaId        OCTET STRING,
          policy          OCTET STRING
      }

LDAP Request Profile

This control is included as part of the controls field of the LDAPMessage, as defined in Section 4.1.12 of [RFC2251].

During the initiation of an LDAP operation, the client can use the IGF Privacy Control and other controls such as the Proxy Authorization Control to pass extended information about the transaction to the server.

The Privacy Control is instantiated and references to the CARML declaration in use and the interaction name identifier (or transaction id) are encoded.

The privacy control may also include WS-Policy statements containing privacy constraints [PRIV-CON] which describe dynamic obligations clients need to declare that may not have been indicated in the CARML declaration.

On an LDAP ADD, MODIFY, or DELETE operation, constraints added are typically due to dynamic conditions not covered in static CARML declaration. Consent constraint conditions such as a Propagate Constraint, or Retention Constraint are examples of conditions which may cause requirements for dynamic constraint specification.

LDAP Response Profile

Editors Note: Are response controls really needed if the client cannot be guaranteed to confirm without first having made a promise during an LDAP Request Message?

This control may be used in any of the "response" type LDAPMessage as part of the controls field of the LDAPMessage, as defined in Section 4.1.12 of [RFC2251]. The control is typically used in compareResponse, searchResultReference, searchResultEntry, and searchResultDone LDAPMessage types.

The IGF Privacy Control is used to convey attribute authority (LDAP Server) constraints on returned data. For message types, compareResult, searchResultReference, or searchResultEntry, the contraint applies to an individual entry. SearchResDone conveys constraints about all entries returned.

Requestor provided constraints (aka obligations or promises) are assumed to apply to the corresponding LDAP response message. The response message need not include any IGF Privacy Control if the response message constraints are the same.

The server may provide additional constraints by specifying an IGF Privacy Control in the response message containing the additional constraints (such as with a dynamic consent condition). Note: that additional constraints are voluntary for the LDAP client as the LDAPMessage also carries response data and compliance cannot be guaranteed.

IANA Considerations

Editor's Notes: (to be removed prior to publication): Result codes, and OID numbers are temporary and must be assigned by IANA.

The OID "1.3.6.1.4.1.31052.1.1", is a temporary private enterprise registration under Liberty Alliance and is currently reserved for the IGF Privacy Control. This number will be changed during the RFC process.

References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2251]
Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2396]
Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2820]
Stokes, E., Byrne, D., Blakley, B., and P. Behera, "Access Control Requirements for LDAP", RFC 2820, May 2000.
[RFC3383]
Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", RFC 3383, September 2002.
[RFC4370]
Weltman, R., "Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control", RFC 4370, February 2006.
[WS-Policy]
W3C World Wide Web Consortium, "WS-Policy Specification: http://www.w3.org/TR/ws-policy/", 2007.
[IGF]
Liberty Alliance, "IGF Specifications, http://www.projectliberty.org/liberty/resource_center/specifications/igf_1_0_specs", 2009.
[CARML]
Liberty Alliance, "CARML Schema Definition http://www.projectliberty.org/liberty/content/download/4326/28930/file/igf-carml.xsd", 2009.
[PRIV-CON]
Liberty Alliance, "IGF Privacy Constraints http://www.projectliberty.org/liberty/content/download/4323/28921/file/draft-liberty-igf-privacy-constraints-v1.0-04.pdf", 2009.
Retrieved from "http://www.openliberty.org/wiki/index.php/Profile_LDAP"
Personal tools
OpenAz