When modifying the LDAP schema to enable Lost Password Management, the LDIF file has to be run against LDAPMODIFY using the command:
ldapmodify -h hostname -p port -D "cn=Directory Manager" -w password -f c:\add.ldif
where add.ldif is the file containing:
dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.9999.1.1094.204 NAME 'Challenge2' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 )
dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.9999.1.1094.205 NAME 'Response2' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 )
# ----------- Object class ---------------
#
dn: cn=schema
changetype: modify
add: objectclasses
objectclasses: ( 1.3.6.1.4.1.9999.1.1094.206 NAME 'oblixAuxPerson4LPM' DESC
'User defined objectclass' SUP top AUXILIARY MAY ( Challenge2 $ Response2 ) )
as per the docs.
Sometimes when you do so, the object class is attempted to be created before the attributes are already created, and this gives an error:
ldap_modify: object class violation
to fix this, separate it into two ldif files, one to create the attributes:
dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.9999.1.1094.204 NAME 'Challenge2' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 )
dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.9999.1.1094.205 NAME 'Response2' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 )
, and the other to create the object class:
# ----------- Object class ---------------
#
dn: cn=schema
changetype: modify
add: objectclasses
objectclasses: ( 1.3.6.1.4.1.9999.1.1094.206 NAME 'oblixAuxPerson4LPM' DESC
'User defined objectclass' SUP top AUXILIARY MAY ( Challenge2 $ Response2 ) )
Wednesday, April 30, 2008
Tuesday, April 29, 2008
Attribute Access Control
From OAM documentation:
The Attribute Access Control function lets you specify permissions that determine who can read and modify the values for each LDAP attribute. It also lets you create a list of users or groups to be notified when an attribute is changed. As with setting the searchbase, this functionality only applies to LDAP attributes. You configure permissions for template objects when you add participants to workflow steps. See "Chaining Identity Functions Into Workflows" for details.Users must have a searchbase defined as well as read permissions to be able to view an attribute. For instance, to be able to view the class attribute on the User Manger, Group Manager, or Organization Manager tab, a user must be a trustee of the appropriate searchbase domain for the class attribute, and they must have read permissions for this attribute.
The Attribute Access Control function lets you specify permissions that determine who can read and modify the values for each LDAP attribute. It also lets you create a list of users or groups to be notified when an attribute is changed. As with setting the searchbase, this functionality only applies to LDAP attributes. You configure permissions for template objects when you add participants to workflow steps. See "Chaining Identity Functions Into Workflows" for details.Users must have a searchbase defined as well as read permissions to be able to view an attribute. For instance, to be able to view the class attribute on the User Manger, Group Manager, or Organization Manager tab, a user must be a trustee of the appropriate searchbase domain for the class attribute, and they must have read permissions for this attribute.
Saturday, August 11, 2007
What is Web Single Sign On?
Web Single Sign-On (SSO) is designed to provide a foundation that gives users role-based access to multiple Web applications from a single, secure point of contact.
Instead of needing to separately log in to multiple applications, users can gain access to any Web application, on any server that is already authorized by their profile.
Instead of needing to separately log in to multiple applications, users can gain access to any Web application, on any server that is already authorized by their profile.
IM Whitepapers by Logic Trends
-Four Quick Wins that Accelerate Identity Management Deployment
-Identity Unification - A Logical Approach
-Why Identity Management Projects Fail... Determines how you can succeed!
Find these interesting white papers by Logic Trends; a leading technology services, consulting, and systems integration firm focused on Identity and Access Management (“IAM”)here.
-Identity Unification - A Logical Approach
-Why Identity Management Projects Fail... Determines how you can succeed!
Find these interesting white papers by Logic Trends; a leading technology services, consulting, and systems integration firm focused on Identity and Access Management (“IAM”)here.
Thursday, July 19, 2007
Single Sign-on and the ObSSoCookie
The Oracle Access System implements single-domain and multi-domain single sign-on
through an encrypted cookie called the ObSSOCookie. The WebGate sends the
ObSSOCookie to the user's browser upon successful authentication. This cookie can
then act as an authentication mechanism for other protected resources that require the same or a lower level of authentication.
When the user requests access to a browser or another resource, the request flows to
the Access Server. The user is logged in, and the ObSSOCookie is set. The Access
Server generates a session token with a URL that contains the ObSSOCookie. Single
sign-on works when the cookie is used for subsequent authorizations in lieu of
prompting the user to supply authorization credentials.
When the cookie is generated, part of the cookie is used as an encrypted session token.
The encrypted session token contains the following information:
- The distinguished name (DN) of the authenticated user.
- The level of the authentication scheme that authenticated the user.
- The IP address of the client to which the cookie was issued.
- The time the cookie was originally issued.
- The time the cookie was last updated.
If the user has not been idle, the cookie is updated at a fixed interval to prevent the session from timing out. The update interval is one-fourth of the length of the idle session timeout parameter.
Unencrypted ObSSOCookie data includes:
- Cookie expiry time.
- The domain in which the cookie is valid.
- An optional flag that determines if the cookie can only be sent using SSL.
Security of the ObSSOCookie
The ObSSOCookie is a secure mechanism for user authentication. When the Access
System generates the cookie, an MD-5 hash is taken of the session token. When the
ObSSOCookie is used to authenticate a user, the MD-5 hash is compared with the
original cookie contents to be sure no one has tampered with the cookie. MD-5 is a
one-way hash, so it cannot be unencrypted. The Access Server does the comparison by
hashing the session token again and comparing the output with the hash of the token
already present in the cookie. If the two hashes do not match, the cookie is corrupt.
The system relies on the fact that if someone tampers with the session token, the
hashes will not match.
The single sign-on cookie does not contain user credentials such as user name and
password.
through an encrypted cookie called the ObSSOCookie. The WebGate sends the
ObSSOCookie to the user's browser upon successful authentication. This cookie can
then act as an authentication mechanism for other protected resources that require the same or a lower level of authentication.
When the user requests access to a browser or another resource, the request flows to
the Access Server. The user is logged in, and the ObSSOCookie is set. The Access
Server generates a session token with a URL that contains the ObSSOCookie. Single
sign-on works when the cookie is used for subsequent authorizations in lieu of
prompting the user to supply authorization credentials.
When the cookie is generated, part of the cookie is used as an encrypted session token.
The encrypted session token contains the following information:
- The distinguished name (DN) of the authenticated user.
- The level of the authentication scheme that authenticated the user.
- The IP address of the client to which the cookie was issued.
- The time the cookie was originally issued.
- The time the cookie was last updated.
If the user has not been idle, the cookie is updated at a fixed interval to prevent the session from timing out. The update interval is one-fourth of the length of the idle session timeout parameter.
Unencrypted ObSSOCookie data includes:
- Cookie expiry time.
- The domain in which the cookie is valid.
- An optional flag that determines if the cookie can only be sent using SSL.
Security of the ObSSOCookie
The ObSSOCookie is a secure mechanism for user authentication. When the Access
System generates the cookie, an MD-5 hash is taken of the session token. When the
ObSSOCookie is used to authenticate a user, the MD-5 hash is compared with the
original cookie contents to be sure no one has tampered with the cookie. MD-5 is a
one-way hash, so it cannot be unencrypted. The Access Server does the comparison by
hashing the session token again and comparing the output with the hash of the token
already present in the cookie. If the two hashes do not match, the cookie is corrupt.
The system relies on the fact that if someone tampers with the session token, the
hashes will not match.
The single sign-on cookie does not contain user credentials such as user name and
password.
Thursday, July 12, 2007
Identity Management Overview Seminar @ ITWorx
A seminar on Identity Management, was held at ITWorx premises as a part of Worx's OraWorx initiative at giving an overview about Oracle's different products.
The seminar was held on the 8th of July, 2007 which provided an overview of Identity Management as a set of technologies and tools, followed by an overview on Oracle Identity Management solutions, along with a quick demo on Oracle Access Manager(OAM).
The seminar was held on the 8th of July, 2007 which provided an overview of Identity Management as a set of technologies and tools, followed by an overview on Oracle Identity Management solutions, along with a quick demo on Oracle Access Manager(OAM).
Thursday, June 28, 2007
Identity Management Explained
Identity Management is an integrated system of business processes, policies and technologies that enable organizations to facilitate and control their users' access to critical online applications and resources — while protecting confidential personal and business information from unauthorized users.
en.wikipedia.org/wiki/Identity_management
en.wikipedia.org/wiki/Identity_management
Subscribe to:
Posts (Atom)
