| Skip Navigation Links | |
| Exit Print View | |
|
Oracle Fusion Middleware Glossary for Oracle Unified Directory 11g Release 1 (11.1.1) |
| Skip Navigation Links | |
| Exit Print View | |
|
|
Oracle Fusion Middleware Glossary for Oracle Unified Directory 11g Release 1 (11.1.1) |
Common Development and Distribution License
deprecated password storage scheme
Directory Services Markup Language
entry change notification control
extensible match search filter
greater than or equal to search filter
less than or equal to search filter
Lightweight Directory Access Protocol
notice of disconnection unsolicited notification
Password Modify extended operation
Simple Authentication and Security Layer
virtual attributes only control
The LDAP abandon operation can be used to request that the server stop processing on an outstanding request. The abandon request protocol op is as follows:
AbandonRequest ::= [APPLICATION 16] MessageID
The message ID provided in the request is the message ID of the operation to abandon.
The abandon operation does not have a response, so there is no way for clients to know whether the abandon operation was successful. Similarly, if an operation was abandoned, then no response will be provided for it, so the client may wait indefinitely for a response that will never be sent. Both of these issues are addressed by the cancel extended operation.
Bind, unbind, abandon, and StartTLS extended operations cannot be abandoned.
An abstract object class is one that cannot be used directly in an entry but must be subclassed by either a structural object class or auxiliary object class. The subclasses will inherit any required and/or optional attribute type defined by the abstract class.
One of the most notable abstract object classes defined in LDAP is the top object class, which is the root class for virtually all other object classes defined in the server schema.
Abstract Syntax Notation One (ASN.1) is a mechanism for encoding data in a binary form. It uses a TLV structure, in which each element has a type, length, and value. The type component is a data type that indicates what kind of information is stored in the element and indicates how the value should be encoded. The length component specifies the number of bytes in the value, and the value is the actual data held by the element.
Examples of ASN.1 elements include the following:
Octet string elements hold a set of zero or more octets (bytes) of data. It can be used for holding string or binary data.
Boolean elements hold values that represent either true or false.
Integer elements hold values that represent integer values.
Enumerated elements hold values that represent integer values where each value has a specific meaning.
Sequence elements are containers that hold zero or more other ASN.1 elements in a manner where the order of the elements is significant.
Set elements are containers that hold zero or more other ASN.1 elements in a manner where the order of the elements is not significant.
Note that ASN.1 is a general framework for binary encoding, but doesn't actually define how the data should be encoded. That is handled by an encoding rule, and there are a number of different kinds of ASN.1 encoding rules. LDAP uses the Basic Encoding Rules encoding, but other types include Distinguished Encoding Rules (DER), Canonical Encoding Rules (CER), and Packed Encoding Rules (PER).
Access control provides a mechanism for restricting who can get access to various kinds of information in the Directory Server. The access control provider can be used to control a number of things, including:
Whether or not a client can retrieve an entry from the server.
Which attributes within the entry the client is allowed to retrieve.
Which values of an attribute the client is allowed to retrieve.
The ways in which the client is able to manipulate data in the directory.
A number of things can be taken into account when making access control decisions, including:
The DN as whom the user is authenticated.
The method by which the client authenticated to the server.
Any groups in which that user is a member.
The contents of the authenticated user's entry.
The contents of the target entry.
The address of the client system.
Whether or not the communication between the client and server is secure.
The time of day and/or day of week of the attempt.
See Chapter 9, Controlling Access To Data, in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory for details on the access control syntax.
In addition to the access control subsystem, the directory server also provides a privilege that can be used to control what a user will be allowed to do. One of the privileges available is the bypass-acl privilege, which can be used to allow that client to bypass any restrictions that the access control subsystem would otherwise enforce.
See access control rule.
An access control rule (also called an access control instruction, or ACI), is a rule which may be used to grant or deny a user or set of users access to perform some kind of operation in the server. The Directory Server access control policy comprises the complete set of access control rules defined in the server.
See Chapter 9, Controlling Access To Data, in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory for more information about the syntax used for access control rules and the operations that can be allowed or denied using them.
The Directory Server access log provides a mechanism for keeping track of every operation processed by the server, including every request received and response returned. It may also be used to obtain information about the internal operations performed within the server.
The directory server provides an extensible framework for implementing access loggers (as well as error and debug loggers). The default access control log implementation writes information to a log file with two records per operation. The first record reflects the request received from the client and the second provides information about the result of the operation processing.
All messages will include a common set of elements including:
The time that the message was logged.
The type of operation being processed.
The connection ID of the client connection that requested the operation.
The operation ID of the operation on that client connection.
The message ID of the message used to request the operation.
For abandon operations, request log messages include the message ID of the operation to abandon. There is no response to an abandon operation, but the server will nevertheless log a result message indicating whether the abandon was successful and the processing time in milliseconds.
For add operations, request log messages include the DN of the entry to add. The response log message may include the result code, diagnostic message, matched DN, the authorization ID for the operation, and the processing time in milliseconds.
For bind operations, request log messages include the authentication type (either SIMPLE or SASL followed by the mechanism name) and the bind DN. The response log message may include the result code, diagnostic message, matched DN, authentication ID, authorization ID, and processing time in milliseconds.
For compare operations, request log messages include the target entry DN and the attribute type. The response log message may include the result code, diagnostic message, matched DN, authorization ID, and the processing time in milliseconds.
For delete operations, request log messages include the target entry DN. The response log message may include the result code, diagnostic message, matched DN, authorization ID, and the processing time in milliseconds.
For extended operations, request log messages include the OID for the extended request. The response log message may include the OID of the extended response, the result code, diagnostic message, matched DN, and the processing time in milliseconds.
For modify operations, request log messages include the target entry DN. The response log message may include the result code, diagnostic message, matched DN, authorization ID, and the processing time in milliseconds.
For modify DN operations, request log messages include the target entry DN, the new RDN, a flag indicating whether to delete the old RDN values, and the new superior DN. The response log message may include the result code, diagnostic message, matched DN, authorization ID, and the processing time in milliseconds.
For search operations, request log messages include the search base DN, scope, filter, and search attributes. The response log message may include the result code, number of entries returned, diagnostic message, matched DN, authorization ID, and the processing time in milliseconds.
For unbind operations, the request message will simply indicate that an unbind request has been received. There is no response to an unbind request, and no result log message.
Account expiration is a component of the Directory Server password policy that may be used to indicate that an account is no longer able to be used beyond a given date. This feature may be useful for creating temporary user accounts (for example, for use by contractors, interns, or other temporary workers) that will expire after a specified date.
Account expiration may be enabled by adding the ds-pwp-account-expiration-time operational attribute to the target user's entry. The value for this attribute should be a time stamp in generalized time format that specifies the time that the account should expire. Once the account expiration time has passed, the user will no longer be allowed to authenticate to the server.
Account lockout is a component of the Directory Server password policy that may be used to lock user accounts after too many failed bind attempts. Once an account has been locked, that user will not be allowed to authenticate. The lockout may be temporary (automatically ending after a specified period of time) or permanent (remaining in effect until an administrator resets the user's password).
An account status notification is a mechanism that can be used to provide indication that a user account has changed in a manner that is significant with regard to the server's password policy.
The types of account status notifications available for use in the server include:
When the user's account has been locked due too many failed attempts
When the user's account has been locked due to remaining idle too long
When the user's account has been unlocked by an administrator
When the user's account has been manually disabled or re-enabled by an administrator
When the user's account has expired
When the user's password has expired or is about to expire
When the user's password has been reset by an administrator
When the user's password has been changed by the end user
The directory server provides an extensible framework for handling account status notifications. The default handler writes messages to the server's error log, but the framework can be used to send email messages or take other actions that may be desired.
The account usability control provides a pair of request and response controls that can be used to determine whether a user account may be used for authenticating to the server.
The request control has an OID of 1.3.6.1.4.1.42.2.27.9.5.8 and does not include a value. It should only be included in search request messages.
The corresponding response control has an OID of 1.3.6.1.4.1.42.2.27.9.5.8 (the same as the request control), and it will be included in any search result entry messages for a search request that includes the account usability request control.
The value for the account usability response control is encoded as follows:
ACCOUNT_USABLE_RESPONSE ::= CHOICE {
is_available [0] INTEGER, -- Seconds before expiration --
is_not_available [1] MORE_INFO }
MORE_INFO ::= SEQUENCE {
inactive [0] BOOLEAN DEFAULT FALSE,
reset [1] BOOLEAN DEFAULT FALSE,
expired [2] BOOLEAN DEFAULT_FALSE,
remaining_grace [3] INTEGER OPTIONAL,
seconds_before_unlock [4] INTEGER OPTIONAL }
If the user account is available, then the control will include the number of seconds until the user's password expires, or -1 if password expiration is not enabled. If the user's account is not available, then the control will provide the reason it is unavailable.
For an example of using this control in a search request, see To Search Using the Account Usability Request Control in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.
ACID is an acronym that stands for Atomicity, Consistency, Isolation, and Durability. This term is standard database terminology that refers to the characteristics that can be achieved using the transactional nature of the database. These elements include:
Each transaction performed in the database is atomic. That is, it either completely succeeds or completely fails. It never partially succeeds such that some changes that are part of the transaction are applied while others are not.
The database is always in a consistent state such that the integrity of its contents will be preserved. It should not be possible for a successful or failed transaction to leave the database in an inconsistent state.
The operations performed as part of a transaction will be isolated from other operations performed in the database at the same time. If one transaction is used to make a number of changes to database contents, then it should not be possible for another transactional operation to see the effects of those changes until they have been committed.
Any transaction that the database has reported as complete and committed successfully is guaranteed to be on persistent storage. Even if the directory server, or the underlying JVM, operating system, or hardware should fail the instant after the notification of the successful commit, then that change will not be lost.
The Berkeley DB Java Edition used as the data store for the primary back end provides full support for ACID compliance, although it also provides methods for relaxing its compliance to these constraints if desirable for performance reasons. The directory server exposes some of this flexibility, particularly with regard to configuring how durable the changes will be (for example, it is possible to configure the server so that changes are not immediately flushed to disk, which may allow better write performance but could cause the loss of one or more changes in the event of a hardware or software failure).
The LDAP add operation can be used to create an entry in the Directory Server. The add request protocol op is defined as follows:
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }
The elements included in this request include the DN of the entry to add and the set of attributes to include in that entry.
The response to an LDAP add operation is an LDAP result element, defined as follows:
AddResponse ::= [APPLICATION 9] LDAPResult
An alias is a special type of entry that references another entry in the server, much like a symbolic link in a UNIX file system. It should include the alias object class and the aliasedObjectName attribute with a value equal to the DN of the entry that it references.
Aliases are primarily used for search operations. In particular, the search request includes an element that specifies the dereference policy that should be used when aliases are encountered. The allowed dereference policy values include:
The server should never dereference alias entries.
The server should dereference any alias entries that it finds in the possible set of search result entries, but if the search base DN specifies an alias entry it will not be dereferenced.
The server should dereference the search base entry if it is an alias, but it will not dereference any aliases within the possible set of search result entries.
The server should dereference any aliases encountered, whether in the search base entry or in the possible set of search result entries.
Note that aliases are an optional part of the LDAPv3 protocol, and the directory server does not currently support them.
An AND search filter is a type of search filter that is intended to serve as a container that holds zero or more other search filters. In order for an entry to match an AND filter, it must match all of the filters contained in that AND filter.
AND filters may be represented as a string by enclosing the entire filter in parentheses and placing an ampersand just after the opening parenthesis. For example, a filter of (&(objectClass=person)(uid=john.doe)) represents an AND search filter that embeds the (objectClass=person) and (uid=john.doe) equality filters.
An AND filter that does not contain any embedded filters is called an LDAP true filter. The string representation for an LDAP true filter is an ampersand (&), and LDAP true filters will always match any target entry.
An anonymous bind is a type of bind operation using simple authentication with a zero-length bind DN and a zero-length password. It may be used to destroy any previous authentication performed on a connection and return it to an unauthenticated state.
Note that there is an ANONYMOUS SASL mechanism that has the same effect, but in general the term “anonymous bind” refers to the simple bind operation with no DN and password.
The ANONYMOUS SASL mechanism is a type of SASL authentication mechanism. It is different from other SASL mechanisms in that it is used to create an unauthenticated session, and will destroy any previous authentication that may have been performed on the connection.
The ANONYMOUS SASL mechanism provides the ability to include trace information in the request that may be included in the server's access log. This trace information can provide information about the client performing the bind, although because no authentication is performed the validity of the trace information cannot be guaranteed.
An approximate index is a type of index that is used to efficiently identify which entries are approximately equal to a given assertion value. An approximate index can be maintained only for attributes that have a corresponding approximate matching rules. That matching rule are used to normalize values to use as index keys, and the value for that key is the ID list containing the entry IDs of the entries with values that are approximately equal to that normalized value.
An approximate search filter is a type of search filter that can be used to identify entries that contain a value for a given attribute that is approximately equal to a given assertion value. The server will use an approximate matching rule to make the determination.
The string representation of an LDAP approximate filter comprises an opening parenthesis followed by the attribute name, a tilde, an equal sign, the attribute value, and the closing parenthesis. For example, an equality filter of (givenName~=John will match any entry in which the givenName attribute contains a value that is approximately equal to John.
See Abstract Syntax Notation One.
An assertion value is the value of an attribute value assertion. The assertion value is provided to a matching rule in order to make a determination about the value of a specified attribute.
An attribute is a named set of values. An attribute has an attribute description, which contains the name of that attribute (which links it to an attribute type) and an optional set of attribute options, and a collection of one or more values.
An entry contains a collection of attributes. It is possible for an entry to have multiple attributes with the same attribute type but different sets of options.
An attribute description is used to identify a given attribute in an entry. An attribute description contains a name or OID that ties it to an attribute type and zero or more attribute options. If the attribute description contains any attribute options, then they are separated from the attribute name/OID by a semicolon, and a semicolon is also used to separate individual attribute options if there is more than one option in the attribute description.
An attribute option is a kind of tag that provides additional information about the way that an attribute should be interpreted. An attribute description consists of the attribute name or OID followed by zero or more attribute options. If there are attribute options, then they are separated from the attribute name and from each other using semicolons. For example, in the attribute description userCertificate;binary, the attribute name is userCertificate and the attribute option is binary.
Attribute options can be used for several purposes, including providing information about how the server should treat that attribute (for example, the binary encoding option as described in RFC 4522) They may also be provided for the benefit of clients in some form (for example, the language tag options as described in RFC 3866, which make it possible to provide an attribute value in different languages).
An attribute syntax is a schema element that defines a kind of data type that is used to dictate the kind of information that may be stored in an attribute value. Any attempt to store an attribute value that violates the syntax for the associated attribute type should be rejected.
Common attribute syntaxes include:
Can hold any kind of data, whether textual or not, that should be compared on a byte-for-byte basis. Note that the binary syntax has been deprecated in favor of the octet string syntax.
Can hold values of either TRUE or FALSE.
Can hold any kind of string value (technically, binary values are allowed as well, but directory string values are typically strings).
Can hold values that are valid DNs.
Can hold values that contain time stamps of varying precision (anywhere from an hour to a fraction of a second) including time zone information. For example, the value 20070525222745Z represents a time stamp of May 25, 2007 at 10:27:45 PM in the UTC time zone.
Can hold values that contain ASCII strings (that is, use of non-ASCII characters is not allowed).
Can hold integer values. Positive, negative, and zero values are allowed.
Can hold any kind of data that should be compared on a byte-for-byte basis.
Can hold a multi-line address, in which the lines of the address should be separated by dollar signs.
Can hold a string containing any combination of printable characters. Printable characters include all uppercase and lowercase ASCII letters, the numeric digits, the space character, and the symbols '()+,-.=/:?.
Can hold telephone number values.
The set of attribute syntaxes defined in the server may be determined by retrieving the ldapSyntaxes attribute of the subschema subentry. For more information about attribute syntaxes, see Understanding Attribute Syntaxes in Oracle Fusion Middleware Architecture Reference for Oracle Unified Directory.
An attribute type is a schema element that correlates an OID and a set of names with an attribute syntax and a set of matching rules.
The components of an attribute type definition include:
An OID used to uniquely identify the attribute type.
A set of zero or more names that can be used to more easily reference the attribute type.
An optional equality matching rule that specifies how equality matching should be performed on values of that attribute. If no equality matching rule is specified, then the default equality rule for the associated attribute syntax will be used. If the associated syntax doesn't have a default equality matching rule, then equality operations will not be allowed for that attribute.
An optional ordering matching rule that specifies how ordering operations should be performed on values of that attribute. If no ordering matching rule is specified, then the default ordering rule for the associated attribute syntax will be used. If the associated syntax doesn't have a default ordering matching rule, then ordering operations will not be allowed for that attribute.
An optional substring matching rule that specifies how substring matching should be performed on values of that attribute. If no substring matching rule is specified, then the default substring rule for the associated attribute syntax will be used. If the associated syntax doesn't have a default substring matching rule, then substring operations will not be allowed for that attribute.
An optional syntax OID that specifies the syntax for values of the attribute. If no syntax is specified, then it will default to the directory string syntax.
A flag that indicates whether the attribute is allowed to have multiple values.
An optional attribute usage string indicating the context in which the attribute is to be used.
An optional flag that indicates whether the attribute can be modified by external clients.
The set of attribute types defined in the server may be determined by retrieving the attributeTypes attribute of the subschema subentry. For more information about attribute types, see Understanding Attribute Types in Oracle Fusion Middleware Architecture Reference for Oracle Unified Directory.
An attribute type's attribute usage defines the contexts in which it may be used. There are four types of attribute usage:
This should be used for all attribute types that are intended for use in holding user-defined data.
This should be used for attribute types that are used for behind-the-scenes processing within the server.
This should be used for attribute types that store operational data that need to be distributed (that is, replicated) throughout the directory environment.
This should be used for attribute types that store operational data that should be stored only in one server and should not be replicated throughout the directory environment.
Attributes with a usage of userApplications are known as user attributes. Attributes with a usage of directoryOperation, distributedOperation, or dSAOperation are known as operational attributes.
An attribute value describes an element of actual data held by an attribute. An attribute may have multiple values, if allowed by the associated attribute type. The way that the server should interact with the values of that attribute is governed by that attribute's syntax and matching rules.
An attribute value assertion (AVA) is a combination of an attribute description and an attribute value. The assertion value is used in conjunction with a matching rule in order to make the determination. If the matching rule is an equality matching rule, then it will be used to determine whether the attribute contains a given value. If it is an ordering matching rule, then the AVA will be used to determine whether the attribute contains a value that is greater than or equal to, or less than or equal to, the assertion value. If it is an approximate matching rule, then the AVA will be used to determine whether the attribute contains a value that is approximately equal to the assertion value. Substring matching is more complex and uses a substring assertion rather than a simple assertion value.
Attribute Value assertions are used in LDAP compare operations, as well as equality, greater or equal, less or equal, and approximate match search filters.
The audit log is a special type of access log that is used to log information about all changes that are made in the server. It provides a log of those changes in LDIF form so that administrators can see exactly what changes were made. This information can be used for diagnostic purposes when investigating a problem, to help better understand the kinds of changes that an application might make in the directory, or to help collect information about changes for replay to an alternate repository.
The name “audit log” is a legacy term referring to its use in the Netscape Directory Server. It should not be confused with a log that could be used for security auditing, as it only records changes to directory data and does not keep track of things like successful or failed authentication attempts. However, in many cases, the combination of the content from the traditional access log and the audit log can be used to obtain this kind of information. If desired, an administrator could also provide a custom access logging implementation to keep track of any kind of desired information.
Authentication is the process whereby a client identifies itself to the directory server and provides proof of its identity. In LDAP, this is performed through the use of a bind operation.
The authentication process has two phases:
The client identifies itself to the server in some way. In simple authentication, the DN provided in the bind request is used for this purpose. In SASL authentication, the identity of the client is obtained through some other means (for example, using a certificate, a Kerberos principal, or some other kind of identifier).
The client must provide sufficient proof that it is who it has identified itself to be. In simple authentication, this is done through the password. In SASL authentication, this verification is obtained in a manner specific to the associated mechanism (it may be a password, or it may be a certificate or some other form of proof).
Some authentication mechanisms may be considered stronger than others. For example, simple authentication may be considered less trustworthy if the client has a password that is easy to guess or obtain through some other means, whereas authentication using a certificate or Kerberos credentials might be considered much stronger and harder to forge. The directory server's access control implementation may be configured to take the client's authentication mechanism into account when determining whether a requested operation will be allowed.
An authentication ID is an identifier that is used by a client to identify itself to the Directory Server for certain kinds of SASL mechanisms (for example, CRAM-MD5, DIGEST-MD5, and PLAIN). It can be used to allow a client to identify itself with a username (or other friendly identifier) rather than a DN.
In most cases, an authentication ID should be specified in one of the following forms:
The string dn: followed by the distinguished name of the target user (or just the string dn: if the authentication identity should be that of the anonymous user).
The string u: followed by a username used to identify the user. An identity mapper will be used to map the provided username to the corresponding user entry.
The authentication password syntax defines a standard method for encoding a user password for storage in the server, ideally in a manner that makes it difficult or impossible to determine the clear-text value of that password.
The authentication password syntax is described in RFC 3112, which defines the authPassword attribute type and a corresponding authPasswordObject auxiliary object class that will allow the use of that attribute.
The basic form of a password encoded using the authentication password syntax is:
scheme $authInfo $ authValue
where scheme is the name of the scheme used to encode the value, authInfo is some kind of modifier (for example, a salt) used in the encoding process, and authValue is the encoded password information. For example, the value SHA1$RzqH67DY3uQ=$atAcDs1eS+IJwPy7V4UDXEoBrDI= is encoded using the authentication password syntax The scheme is SHA1, the authInfo element is RzqH67DY3uQ=, and the authValue element is atAcDs1eS+IJwPy7V4UDXEoBrDI=.
The authentication password schemes supported by the directory server include the following:
Uses the MD5 message digest.
Uses the SHA-1 variant of the Secure Hash Algorithm.
Uses the 256-bit SHA-2 variant of the Secure Hash Algorithm.
Uses the 384-bit SHA-2 variant of the Secure Hash Algorithm.
Uses the 512-bit SHA-2 variant of the Secure Hash Algorithm.
Authorization is the process of determining whether a user will be allowed to perform a requested operation. A number of server components may be involved in the authorization process, including:
The access control handler.
The privilege subsystem.
The password policy.
Custom plug-ins installed in the server.
An authorization ID is an identifier that is used by a client to indicate that one or more operations should be performed under the authority of an alternate identity. This alternate authorization identity can last for a single operation (when used in conjunction with the proxied authorization control) or for the entire duration of an authentication session (when used in conjunction with an appropriate SASL mechanism, like DIGEST-MD5, GSSAPI, or PLAIN).
In most cases, an authorization ID should be specified in one of the following forms:
The string dn: followed by the distinguished name of the target user (or just the string dn: if the authorization identity should be that of the anonymous user).
The string u: followed by a username used to identify the user. An identity mapper maps the provided username to the corresponding user entry.
The ability for a client to use an alternate authorization identity is controlled by the proxied-auth privilege. In some cases, additional access control rights may also be required.
The authorization identity controls are a pair of request and response controls defined in RFC 3829 that can be used in conjunction with an LDAP bind operation to allow the client to learn the authorization identity for the client connection.
The authorization identity request control has an OID of 2.16.840.1.113730.3.4.16 and does not have a value. The authorization identity response control has an OID of 2.16.840.1.113730.3.4.15 and the value of that control should be a string representing the authorization identify for that connection (or an empty string if the authorization identity is that of the anonymous user). The response control should only be included in the response if the authentication was successful.
Note that the authorization identity controls are only allowed for use in conjunction with the LDAP bind operation, and therefore cannot be used after the client has authenticated. The “Who Am I?” extended operation can be used to obtain the authorization identity at any time after the bind has completed.
For an example of using this control in a search request, see To Search Using the Authorization Identity Request Control in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.
An auxiliary object class is one that does not define the core type of an entry, but defines additional characteristics of that entry. An entry can contain zero or more auxiliary object classes. The set of auxiliary classes allowed for use in an entry may be controlled by a DIT content rule associated with that entry's structural object class.
|