LDAP is a directory server.

Directory server is something which holds information

like people,hardware etc about the organization.
IDM deals with People's data (i.e human resources) .LDAP stores these identites
in IDM using the user object with multiple attritbutes like first name , last na
me etc . But the naming convention is different when compared with IDM standards
.Hence we configure those in the resource mappings

LDAP is a standard specification. Sun One is a type of LDAP Implementation. Simi

larly, Active directory is a Microsoft LDAP Implementation.

Implementation in Organization :
They have userid and password in LDAP . when ever they implement the web applica
tion in organization ,they try to authenticate against LDAP credentials.

Difference between IDM & LDAP is that in IDM we will create multiple attributes
for first name, last name etc. where as in LDAP we group them into object class
to manage its easy. In the futue if you want to add these to directory server th
en just add the object class and it will enable and add all the attributes.

Implementation of LDAP in Vendors site.

1.Implement security so that people who have access should be able to access tho
se.

What is LDIF ?
Common command line utility interact with LDAP.
The LDAP Data Interchange Format (LDIF) is a standard plain text data interchang
e format for representing LDAP (Lightweight Directory Access Protocol) directory
content and update requests. LDIF conveys directory content as a set of records
, one record for each object (or entry). It represents update requests, such as
Add, Modify, Delete, and Rename, as a set of records, one record for each update
request.

How do you identify a particular entry into the directory server ?

Its not possible to give a unique id for every user.So LDAP follows X.501 naming
convetion for

--------------------------------------------------------------------------------
--------------------

What is IDM
Identity management (IdM) is a process used to create
and remove a user s digital identity and manage how the
user is able to access electronic resources such as networks,
files, or services

form: form is an object which contains set of rules about how the browser should
display user view attribute on that page
Workflow: Sequence of actions & tasks that are performed according to set of pro
cedural rules
some default workflow processes are user,idm object and miscellaneous workflows
through form generator user view is integrated with forms
Xpress expressions are used to add transformation capabilities to forms and to i
ncorporate state transition logic
with in objects such as workflow and forms

how did you develop various workflows and java classes for user management using
XPRESS Language
How did you install on LINUX Operating System.
Step by step installation.
IDM along with Oracle or Any database
Webserver
Directory servers.

View & Form

A View is a collection of attributes of all resources. Form comprises of a set
of rules used in transforming view data and describe how it is to be displayed.
Views & Workflow
While transforming the data in views ,a new workflow is launched.
A new workflow will be launched to complete the modifications specified by view
.

XML :
SPML :

Unbound ID
Active sync : Can detect native changes in the resource and populate them in IDM
and can also update other resources

-------------------------------------------------------
1-How did you Installed and configured Sun Identity Manager 7.1 on Linux Operati
ng system.?
2-What is self-service and single sign-on (SSO) to foster customer satisfaction
and loyalty.?
3-How did you Developed various custom workflows and java classes for user manag
ement using XPRESS language.?
4-How did you Created various reconciliation policies and integrated different
resource adapters like Microsoft Active Directory.?
5-What is Implementation of providing access to the User for Active Directory ac
counts in various domains.?
6-How did you Involved in development of Audit Logging through Workflow for all
the functionalities.?
7-How did you Documented the test cases and results and handled end user support
for their respective application provisioned.?
8-what is provisioning and deprovisioning.?
9-what is webservices.?
10-what is ESB.?
11-What is SOA.?
12-what is SAML,SPML and XACML.? why do we use this.?
13-What is LDIF.?
14-What is Active Directory and Sundirectory server.?

-------------------------------------------------

LDAP (Lightweight Directory Access Protocol) is a protocol provides a common lan

guage that client applications and servers use to communicate with one another.
LDAP applications can easily search, add, delete and modify directory entries.LD
AP stores the information in IDM using the user object with multiple attritbutes
like first name , last name etc.In the futue if you want to add these to direct
ory server then just add the object class and it will enable and add all the at
tributes.

What is LDIF ?
Common command line utility interact with LDAP.
The LDAP Data Interchange Format (LDIF) is a standard plain text data interchang
e format for representing LDAP (Lightweight Directory Access Protocol) directory
content and update requests. LDIF conveys directory content as a set of records
, one record for each object (or entry). It represents update requests, such as
Add, Modify, Delete, and Rename, as
a set of records, one record for each update request.

--------------------------------------------------------------------------------
-------------------------------------

The Lightweight Directory Access Protocol, or LDAP (pronounced /'?l dæp/), is an a

pplication protocol for querying and modifying directory services running over T
CP/IP.[1]
A directory is a set of objects with attributes organized in a logical and hiera
rchical manner. A simple example is the telephone directory, which consists of a
list of names (of either persons or organizations) organized alphabetically, wi
th each name having an address and phone number associated with it.
An LDAP directory tree often reflects various political, geographic, and/or orga
nizational boundaries, depending on the model chosen. LDAP deployments today ten
d to use Domain name system (DNS) names for structuring the topmost levels of th
e hierarchy. Deeper inside the directory might appear entries representing peopl
e, organizational units, printers, documents, groups of people or anything else
that represents a given tree entry (or multiple entries).
Its current version is LDAPv3, which is specified in a series of Internet Engine
ering Task Force (IETF) Standard Track Requests for comments (RFCs) as detailed
in RFC 4510.

Origin and influences

Telecommunication companies introduced the concept of directory services to info
rmation technology and computer networking, since their understanding of directo
ry requirements was well-developed after some 70 years of producing and managing
telephone directories. The culmination of this input was the comprehensive X.50
0 specification[2], a suite of protocols produced by the International Telecommu
nication Union (ITU) in the 1980s.
X.500 directory services were traditionally accessed via the X.500 Directory Acc
ess Protocol (DAP), which required the Open Systems Interconnection (OSI) protoc
ol stack. LDAP was originally intended to be a lightweight alternative protocol
for accessing X.500 directory services through the simpler (and now widespread)
TCP/IP protocol stack. This model of directory access was borrowed from the DIXI
E and Directory Assistance Service protocols.
Standalone LDAP directory servers soon followed, as did directory servers suppor
ting both DAP and LDAP. The latter has become popular in enterprises, as LDAP re
moved any need to deploy an OSI network. Today, X.500 directory protocols includ
ing DAP can also be used directly over TCP/IP.
The protocol was originally created by Tim Howes of the University of Michigan,
Steve Kille of Isode Limited, and Wengyik Yeong of Performance Systems Internati
onal, circa 1993. Further development has come through the Internet Engineering
Task Force.
In the early engineering stages of LDAP, it was known as Lightweight Directory B
rowsing Protocol, or LDBP. It was renamed with the expansion of the scope of the
protocol to include beyond directory browsing and searching functions, also dir
ectory update functions.
LDAP has influenced subsequent Internet protocols, including later versions of X
.500, XML Enabled Directory (XED), Directory Service Markup Language (DSML), Ser
vice Provisioning Markup Language (SPML), and the Service Location Protocol (SLP
).
[edit] Protocol overview
A client starts an LDAP session by connecting to an LDAP server, called a Direct
ory System Agent (DSA), by default on TCP port 389. The client then sends an ope
ration request to the server, and the server sends responses in return. With som
e exceptions, the client need not wait for a response before sending the next re
quest, and the server may send the responses in any order.
The client may request the following operations:
Start TLS use the LDAPv3 Transport Layer Security (TLS) extension for a secure c
onnection
Bind authenticate and specify LDAP protocol version
Search search for and/or retrieve directory entries
Compare test if a named entry contains a given attribute value
Add a new entry
Delete an entry
Modify an entry
Modify Distinguished Name (DN) move or rename an entry
Abandon abort a previous request
Extended Operation generic operation used to define other operations
Unbind close the connection (not the inverse of Bind)
In addition the server may send "Unsolicited Notifications" that are not respons
es to any request, e.g. before it times out a connection.
A common alternate method of securing LDAP communication is using an SSL tunnel.
This is denoted in LDAP URLs by using the URL scheme "ldaps". The default port
for LDAP over SSL is 636. The use of LDAP over SSL was common in LDAP Version 2
(LDAPv2) but it was never standardized in any formal specification. This usage h
as been deprecated along with LDAPv2, which was officially retired in 2003.
LDAP is defined in terms of ASN.1, and protocol messages are encoded in the bina
ry format BER. It uses textual representations for a number of ASN.1 fields/type
s, however.
[edit] Directory structure
The protocol accesses LDAP directories, which follow the 1993 edition of the X.5
00 model:
A directory is a tree of directory entries.
An entry consists of a set of attributes.
An attribute has a name (an attribute type or attribute description) and one or
more values. The attributes are defined in a schema (see below).
Each entry has a unique identifier: its Distinguished Name (DN). This consists o
f its Relative Distinguished Name (RDN) constructed from some attribute(s) in th
e entry, followed by the parent entry's DN. Think of the DN as a full filename a
nd the RDN as a relative filename in a folder.
Be aware that a DN may change over the lifetime of the entry, for instance, when
entries are moved within a tree. To reliably and unambiguously identify entries
, a UUID might be provided in the set of the entry's operational attributes.
An entry can look like this when represented in LDAP Data Interchange Format (LD
IF) (LDAP itself is a binary protocol):
dn: cn=John Doe,dc=example,dc=com
cn: John Doe
 givenName: John
sn: Doe
telephoneNumber: +1 888 555 6789
telephoneNumber: +1 888 555 1232
mail: john@example.com
manager: cn=Barbara Doe,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
dn is the name of the entry; it's not an attribute nor part of the entry. "cn=Jo
hn Doe" is the entry's RDN (Relative Distinguished Name), and "dc=example,dc=com
" is the DN of the parent entry, where dc denotes Domain Component. The other li
nes show the attributes in the entry. Attribute names are typically mnemonic str
ings, like "cn" for common name, "dc" for domain component, "mail" for e-mail ad
dress and "sn" for surname.
A server holds a subtree starting from a specific entry, e.g. "dc=example,dc=com
" and its children. Servers may also hold references to other servers, so an att
empt to access "ou=department,dc=example,dc=com" could return a referral or cont
inuation reference to a server which holds that part of the directory tree. The
client can then contact the other server. Some servers also support chaining, wh
ich means the server contacts the other server and returns the results to the cl
ient.
LDAP rarely defines any ordering: The server may return the values of an attribu
te, the attributes in an entry, and the entries found by a search operation in a
ny order. This follows from the formal definitions - an entry is defined as a se
t of attributes, and an attribute is a set of values, and sets need not be order
ed.
[edit] Operations
The client gives each request a positive Message ID, and the server response has
the same Message ID. The response includes a numeric result code which indicate
s success, some error condition or some other special cases. Before the response
, the server may send other messages with other result data - for example each e
ntry found by the Search operation is returned in such a message.
Expand discussion of referral responses to various operations, especially modify
, for example where all modifies must be directed from replicas to a master dire
ctory.
[edit] StartTLS
The StartTLS operation establishes Transport Layer Security (the descendant of S
SL) on the connection. That can provide data confidentiality (to protect data fr
om being observed by third parties) and/or data integrity protection (which prot
ects the data from tampering). During TLS negotiation the server sends its X.509
certificate to prove its identity. The client may also send a certificate to pr
ove its identity. After doing so, the client may then use SASL/EXTERNAL. By usin
g the SASL/EXTERNAL, the client requests the server derive its identity from cre
dentials provided at a lower level (such as TLS). Though technically the server
may use any identity information established at any lower level, typically the s
erver will use the identity information established by TLS.
Servers also often support the non-standard "LDAPS" ("Secure LDAP", commonly kno
wn as "LDAP over SSL") protocol on a separate port, by default 636. LDAPS differ
s from LDAP in two ways: 1) upon connect, the client and server establish TLS be
fore any LDAP messages are transferred (without a Start TLS operation) and 2) th
e LDAPS connection must be closed upon TLS closure.
LDAPS was used with LDAPv2, because the StartTLS operation had not yet been defi
ned. The use of LDAPS is deprecated, and modern software should only use StartTL
S .
[edit] Bind (authenticate)
The Bind operation authenticates the client to the server. Simple Bind can send
the user's DN and password in plaintext, so the connection should be protected u
sing Transport Layer Security (TLS). The server typically checks the password ag
ainst the userPassword attribute in the named entry. Anonymous Bind (with empty
DN and password) resets the connection to anonymous state. SASL (Simple Authenti
cation and Security Layer) Bind provides authentication services through a wide
range of mechanisms, e.g. Kerberos or the client certificate sent with TLS.
Bind also sets the LDAP protocol version. Normally clients should use LDAPv3, wh
ich is the default in the protocol but not always in LDAP libraries.
Bind had to be the first operation in a session in LDAPv2, but is not required i
n LDAPv3 (the current LDAP version).
[edit] Search and Compare
The Search operation is used to both search for and read entries. Its parameters
are:
baseObject
The DN (Distinguished Name) of the entry at which to start the search,
scope
What elements below the baseObject to search. This can be BaseObject (search jus
t the named entry, typically used to read one entry), singleLevel (entries immed
iately below the base DN), or wholeSubtree (the entire subtree starting at the b
ase DN).
filter
Criteria to use in selecting elements within scope. For example, the filter (&(o
bjectClass=person)(|(givenName=John)(mail=john*))) will select "persons" (elemen
ts of objectClass person) who either have the given name "John" or an e-mail add
ress that begins with the string "john".
derefAliases
Whether and how to follow alias entries (entries which refer to other entries),
attributes
Which attributes to return in result entries.
sizeLimit, timeLimit
Maximum number of entries to return, and maximum time to allow search to run.
typesOnly
Return attribute types only, not attribute values.
The server returns the matching entries and potentially continuation references.
These may be returned in any order.The final result will include the result cod
e.
The Compare operation takes a DN, an attribute name and an attribute value, and
checks if the named entry contains that attribute with that value.
[edit] Update Data
Add, Delete, and Modify DN - all require the DN of the entry that is to be chang
ed.
Modify takes a list of attributes to modify and the modifications to each: Delet
e the attribute or some values, add new values, or replace the current values wi
th the new ones.
Add operations also can have additional attributes and values for those attribut
es.
Modify DN (move/rename entry) takes the new RDN (Relative Distinguished Name), o
ptionally the new parent's DN, and a flag which says whether to delete the value
(s) in the entry which match the old RDN. The server may support renaming of ent
ire directory subtrees.
An update operation is atomic: Other operations will see either the new entry or
the old one. On the other hand, LDAP does not define transactions of multiple o
perations: If you read an entry and then modify it, another client may have upda
ted the entry in the mean time. Servers may implement extensions [3] which suppo
rt this, however.
[edit] Extended operations
The Extended Operation is a generic LDAP operation which can be used to define n
ew operations. Examples include the Cancel, Password Modify and Start TLS operat
ions.
[edit] Abandon
The Abandon operation requests that the server abort an operation named by a mes
sage ID. The server need not honor the request. Unfortunately, neither Abandon n
or a successfully abandoned operation send a response. A similar Cancel extended
operation has therefore been defined which does send responses, but not all imp
lementations support this.
[edit] Unbind
The Unbind operation abandons any outstanding operations and closes the connecti
on. It has no response. The name is of historical origin, and is not the opposit
e of the Bind operation.[4]
Clients can abort a session by simply closing the connection, but they should us
e Unbind.[5] Unbind allows the server to gracefully close the connection and fre
e resources that it would otherwise keep for some time until discovering the cli
ent had abandoned the connection. It also instructs the server to cancel operati
ons that can be canceled, and to not send responses for operations that cannot b
e canceled.[6]
[edit] LDAP URLs
An LDAP URL format exists which clients support in varying degree, and which ser
vers return in referrals and continuation references (see RFC 4516):
ldap://host:port/DN?attributes?scope?filter?extensions
Most of the components, which are described below, are optional.
host is the FQDN or IP address of the LDAP server to search.
port is the network port of the LDAP server.
DN is the distinguished name to use as the search base.
attributes is a comma-separated list of attributes to retrieve.
scope specifies the search scope and can be "base" (the default), "one" or "sub"
.
filter is a search filter. For example (objectClass=*) as defined in RFC 4515.
extensions are extensions to the LDAP URL format.
For example, "ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=com" refers to
all user attributes in John Doe's entry in ldap.example.com, while "ldap:///dc=
example,dc=com??sub?(givenName=John)" searches for the entry in the default serv
er (note the triple slash, omitting the host, and the double question mark, omit
ting the attributes). As in other URLs, special characters must be percent-encod
ed.
There is a similar non-standard ldaps: URL scheme for LDAP over SSL. This should
not be confused with LDAP with TLS, which is achieved using the StartTLS operat
ion using the standard ldap: scheme.
[edit] Schema
The contents of the entries in a subtree are governed by a schema known as Direc
tory Information Tree (DIT).
The schema of a Directory Server defines a set of rules that govern the kinds of
information that the server can hold. Directory schema is comprised of a number
of different elements, including:
Attribute Syntaxes -- Provide information about the kind of information that can
be stored in an attribute.
Matching Rules -- Provide information about how to make comparisons against attr
ibute values.
Matching Rule Uses -- Indicate which attribute types may be used in conjunction
with a particular matching rule.
Attribute Types -- Define an OID and a set of names that may be used to refer to
a given attribute, and associates that attribute with a syntax and set of match
ing rules.
Object Classes -- Define named collections of attributes and classify them into
sets of required and optional attributes.
Name Forms -- Define rules for the set of attributes that should be included in
the RDN for an entry.
Content Rules -- Define additional constraints about the object classes and attr
ibutes that may be used in conjunction with an entry.
Structure Rule -- Define rules that govern the kinds of subordinate entries that
a given entry may have.
Attributes are the elements responsible for storing information in a directory,
and the schema defines the rules for which attributes may be used in an entry, t
he kinds of values that those attributes may have, and how clients may interact
with those values.
Clients may learn about the schema elements that the server supports by retrievi
ng an appropriate subschema subentry.
The schema defines object classes. Each entry must have an objectClass attribute
, containing named classes defined in the schema. The schema definition of the c
lasses of an entry defines what kind of object the entry may represent - e.g. a
person, organization or domain. The object class definitions also define the lis
t of attributes that must contain values and the list of attributes which may co
ntain values.
For example, an entry representing a person might belong to the classes "top" an
d "person". Membership in the "person" class would require the entry to contain
the "sn" and "cn" attributes, and allow the entry also to contain "userPassword"
, "telephoneNumber", and other attributes. Since entries may have multiple Objec
tClasses values, each entry has a complex of optional and mandatory attribute se
ts formed from the union of the object classes it represents. ObjectClasses can
be inherited, and a single entry can have multiple ObjectClasses values which de
fine the available and required attributes of the entry itself. A parallel to th
e schema of an objectClass is a class definition and an instance in Object-orien
ted programming, representing LDAP objectClass and LDAP entry, respectively.
Directory servers may publish the directory schema controlling an entry at a bas
e DN given by the entry's subschemaSubentry operational attribute. (An operation
al attribute describes operation of the directory rather than user information a
nd is only returned from a search when it is explicitly requested.)
Server administrators can add additional schema entries in addition to the provi
ded schema elements. A schema for representing individual people within organiza
tions is termed a white pages schema.
[edit] Variations
A lot of the server operation is left to the implementor or administrator to dec
ide. Accordingly, servers may be set up to support a wide variety of scenarios.
For example, data storage in the server is not specified - the server may use fl
at files, databases, or just be a gateway to some other server. Access control i
s not standardized, though there has been work on it and there are commonly used
models. Users' passwords may be stored in their entries or elsewhere. The serve
r may refuse to perform operations when it wishes, and impose various limits.
Most parts of LDAP are extensible. Examples: One can define new operations. Cont
rols may modify requests and responses, e.g. to request sorted search results. N
ew search scopes and Bind methods can be defined. Attributes can have options th
at may modify their semantics.
[edit] Other data models
As LDAP has gained momentum, vendors have provided it as an access protocol to o
ther services. The implementation then recasts the data to mimic the LDAP/X.500
model, but how closely this model is followed varies. For example, there is soft
ware to access SQL databases through LDAP, even though LDAP does not readily len
d itself to this.[7] X.500 servers may support LDAP as well.
Similarly, data which were previously held in other types of data stores are som
etimes moved to LDAP directories. For example, Unix user and group information c
an be stored in LDAP and accessed via PAM and NSS modules. LDAP is often used by
other services for Authentication.
[edit] Usage
[edit] Naming structure
Since an LDAP server can return referrals to other servers for requests the serv
er itself will not/can not serve, a naming structure for LDAP entries is needed
so one can find a server holding a given DN. Since such a structure already exis
ts in the Domain name system (DNS), servers' top level names often mimic DNS nam
es, as they do in X.500.
If an organization has domain name example.org, its top level LDAP entry will ty
pically have the DN dc=example,dc=org (where dc means domain component). If the
LDAP server is also named ldap.example.org, the organization's top level LDAP UR
L becomes ldap://ldap.example.org/dc=example,dc=org.
Below the top level, the entry names will typically reflect the organization's i
nternal structure or needs rather than DNS names.
[edit] Terminology
The LDAP terminology one can encounter is rather cumbersome. Some of this is due
to misunderstandings, other examples are due to its historical origins, others
arise when used with non-X.500 services that use different terminology. For exam
ple, "LDAP" is sometimes used to refer to the protocol, other times to the proto
col and the data. An "LDAP directory" may be the data or also the access point.
An "attribute" may be the attribute type, or the contents of an attribute in a d
irectory, or an attribute description (an attribute type with options). An "anon
ymous" and an "unauthenticated" Bind are different Bind methods that both produc
e anonymous authentication state, so both terms are being used for both variants
. The "uid" attribute should hold user names rather than numeric user IDs.