Wednesday Dec 16, 2015

Using OUD plugin for SAML authentication with OAM against users stored in SQLServer

Here is a practical example about how to use a custom OUD plugin to speed up deployment of an Identity Management solution for a fraction of the price compared to developing a custom connector:

The use-case is to enable SAML authentication as an IDP where some of the users are stored in a SQLServer database and some in AD (external users in DB, internal users in AD).

The customer is planning to have OAM authenticate the users and perform the role of a SAML IDP doing LDAP authentication for users stored in the database and Kerberos for the users stored in AD. In order to allow OAM to authenticate users that are stored in the database, OUD can be deployed as a RDBMS proxy thanks to the RDBMS workflow element feature, so that users stored in a database table are exposed as a LDAP tree that OAM will authenticate against.

Problem is with the password field in the database that is hashed in a specific way.  

The trick is to deploy a custom OUD plugin component ahead of the RDBMS workflow element. That plugin is responsible for processing bind requests only. Upon reception of a bind request against a user stored in SQLServer, the custon plugin retrieves the user entry containing hashed password and salt, accesses the plain text password provided in the bind request, and performs the password comparison based on custom logic. 

Design, dev and testing took me a couple of days, much simpler and cost effective than adding support for this new source in OAM/OIM.


Tuesday Dec 15, 2015

Oracle E-Business Suite certified with Unified Directory

Oracle Unified Directory 11gR2 Patchset 3 ( is now certified for use with Oracle E-Business Suite Release 12.2.

Oracle Unified Directory 11gR2 Patchset 3 ( (along with Directory Integration Platform 11gR1 Patchset 7 ( can be integrated with Oracle Access Manager 11gR2 Patchset 3 ( as a single sign-on solution. For availability and other information on Oracle Unified Directory, refer to the articles listed in the documentation section below.

  • My Oracle Support Knowledge Document 2003483.1 - Integrating Oracle E-Business Suite Release 12.2 with Oracle Unified Directory 11gR2 
  • My Oracle Support Knowledge Document 1576425.1 - Integrating Oracle E-Business Suite Release 12.2 with Oracle Access Manager 11gR2 (11.1.2) using Oracle E-Business Suite AccessGate
  • My oracle Support Knowledge Document 1388152.1 - Overview of Single Sign-On Integration Options for Oracle E-Business Suite
  • Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management 11g Release 2 (11.1.2) (E27301-04)
  • Oracle Fusion Middleware Installation Guide for Oracle Unified Directory 11g Release 2 (11.1.2) (E23737-02)
  • Oracle Fusion Middleware Installing Oracle Unified Directory 11g Release 2 (11.1.2) (E56132-02)
  • Oracle Fusion Middleware Installation Guide for Oracle Identity Management 11g Release 1 ( (E12002-13)
  • Oracle Fusion Middleware Administrator's Guide for Oracle Unified Directory 11g Release 2 (11.1.2) (E22648-02)
  • Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform (E56469-01)
  • Oracle Fusion Middleware Patching Guide 11g Release 1 ( (E16793-28)
  • Thursday Sep 10, 2015

    Migration from OID to OUD: Adapting EUS metadata

    Enterprise User Security is an important component of Oracle Database Enterprise Edition. It enables you to address administrative and security challenges for a large number of enterprise database users by centralizing users and roles in a LDAP directory.

    It is possible to use either Oracle Internet Directory (OID) or Oracle Unified Directory (OUD) as LDAP repository for EUS.

    To migrate from OID to OUD, 
    - enable EUS support in OUD
    - copy your user and groups in <your_context)
    - copy across EUS metadata (in cn=oracleContext,<your suffix)

    EUS metadata as stored in OID must be slighly adapted before being impoorted to OUD otherwise the DB won't be able to authenticate against OUD and will raise the following error:

    ORA-28043: invalid bind credentials for DB-OID connection

    Migrating the DB entry from OID to OUD requires some specific steps for SASL/DIGEST-MD5 authentication. In OID, the password hash used for SASL/DIGEST-MD5 authentication is stored in authpassword;oid, with the {SASL/MD5} prefix.
    In OUD, this must be stored in orclcommonrpwdattribute with the {SASL-MD5} prefix.

    For instance:

    In OID:
    ldapsearch [conn details] -b cn=oraclecontext,dc=example,dc=com -s one "(cn=orcl11g)" authpassword
    dn: cn=orcl11g,cn=oraclecontext,dc=example,dc=com
    authpassword;oid: {SASL/MD5}ola+G+GFsSeiu6QcRiAh9g==
    authpassword;oid: {SASL/MD5-DN}3UeqmU5Axd+XVAM9Lxf28g==
    authpassword;oid: {SASL/MD5-U}BD6uyBcSiFbGtlPzq6TtUA==

    In OUD:
    ldapsearch [conn details] -b cn=oraclecontext,dc=example,dc=com -s one "(objectclass=orcldbserver)" orclcommonrpwdattribute
    dn: cn=orcl11g,cn=OracleContext,dc=example,dc=com
    orclcommonrpwdattribute: {SASL-MD5}ola+G+GFsSeiu6QcRiAh9g==

    Friday Sep 04, 2015

    Integrating OUD in Monitoring Frameworks: Service Users

    Oracle Unified Directory is an all-in-one directory solution with storage, proxy, synchronization and virtualization capabilities.

    It can be monitored and integrated in various Monitoring Solutions including Oracle Enterprise Manager, via a dedicated plugin that provides performance monitoring of hundreds of directory metrics, raise alerts based on thresholds and provides rich out-of-the-box reports. By default, monitoring data are retrieved from OUD over LDAPS from the OUD administration port.

    In order to use this method, it is recommended to define a dedicated directory user with read privilege on monitoring statistics and configuration. Such user can either be a so-called Root User or a Global Admin User. Root Users are local to a OUD instance and have some special privileges. Global Admin Users are quite similar to Root Users except that they are replicated across OUD servers, so this is more convenient if you want to monitor several OUD instances.

    The following rights and privileges are required to access monitoring data and config:  Read access on cn=config and cn=monitor naming contexts and config-read privilege.

    Root Users automatically inherit a bunch of default privileges, much more than what is strictly needed to monitor OUD, so unnecessary privileges must be removed and read access must be granted. To create a Root User called "cn=monitor" with sufficient privileges , do the following

    ./ldapmodify  -h <hostname> -p <adminport> \
    -D "cn=Directory Manager" -w <password> -X --useSSL  <<EOF
    dn : cn=monitor,cn=Root DNs,cn=config
    changetype: add
    objectclass: inetOrgPerson
    objectclass: person
    objectclass: ds-cfg-root-dn-user
    objectclass: top
    userPassword: <password>
    ds-cfg-alternate-bind-dn: cn=monitor
    cn: monitor
    sn: monitor


    Let's remove unnecessary privileges (basically all but config-read)

    ./ldapmodify  -h <hostname> -p <adminport> \
    -D "cn=Directory Manager" -w <password> -X --useSSL <<EOF
    dn : cn=monitor,cn=Root DNs,cn=config
    changetype: modify
    add: ds-privilege-name
    ds-privilege-name: -config-write
    ds-privilege-name: -modify-acl
    ds-privilege-name: -ldif-import
    ds-privilege-name: -ldif-export
    ds-privilege-name: -backend-backup
    ds-privilege-name: -backend-restore
    ds-privilege-name: -server-shutdown
    ds-privilege-name: -server-restart
    ds-privilege-name: -disconnect-client
    ds-privilege-name: -cancel-request
    ds-privilege-name: -unindexed-search
    ds-privilege-name: -password-reset
    ds-privilege-name: -update-schema
    ds-privilege-name: -privilege-change
    ds-privilege-name: -bypass-acl

    If you prefer to use Global Admin Users, do the following:

    ./ldapmodify  -h <hostname> -p <adminport> \ 
    -D "cn=Directory Manager" -w <password> -X --useSSL <<EOF
    dn : cn=monitor,cn=Administrators,cn=admin data
    changetype: add
    objectclass: person
    objectclass: top
    userPassword: <password>
    cn: monitor
    sn: monitor


    Let's add config-read privilege:

    ./ldapmodify  -h <hostname> -p <adminport> -D "cn=Directory Manager" -w <password> -X -Z <<EOF
    dn : cn=monitor,cn=Administrators,cn=admin data
    changetype: modify
    add: ds-privilege-name
    ds-privilege-name: config-read


    No matter what User type you choose to use, you need to grant read access to the config and the monitoring information using OUD global acis:
    For Root Users, add the following acis using dsconfig: Start dsconfig, select Authentication and Authorization, then Access Control Handler and add the 2 following global acis:

    (target="ldap:///cn=config")(targetattr="*")(version 3.0; acl "Monitor config access"; allow (read,search) \
      userdn="ldap:///cn=monitor,cn=Root DNs,cn=config";)
    (target="ldap:///cn=monitor")(targetattr="*")(version 3.0; acl "Monitor access"; allow (read,search) \
      userdn="ldap:///cn=monitor,cn=Root DNs,cn=config";) 

    For Global Admin Users, here are the corresponding acis:

    (target="ldap:///cn=config")(targetattr="*")(version 3.0; acl "Monitor config access"; allow (read,search) \
      userdn="ldap:///cn=monitor,cn=administrators,cn=admin data";) 
    (target="ldap:///cn=monitor")(targetattr="*")(version 3.0; acl "Monitor access"; allow (read,search) \
      userdn="ldap:///cn=monitor,cn=administrators,cn=admin data";) 


    At that stage, config and monitoring stats are available from the OUD admin port to the cn=monitor user (if you choose to use Root Users) or to cn=monitor,cn=administrators,cn=admin data (for Global Admins).:

    Monday Jul 20, 2015

    OUD Directory Server vs Replication Server: Who Cares ?

    Oracle Unified Directory replication model relies on 2 logical components, Directory Servers and Replication Servers. Directory Servers contain user data, pushes changes to replication changed and get updates from replication servers. Replication Server stores replication changes, they receive changes to directory servers and forward them to the rest of the topology.

    By default, you don't need to care about Replication Servers. Replication Servers and internal components managed automatically: a Replication Server is autimatically configured in each OUD DIrectory Server process when replication is configured.

    OUD Replication Server and Directory Servers are NOT equivalent to DSEE Suppliers and Consumers. By default, every replicated OUD is a Read-Write Supplier/Master.

    When do you need to know about replication servers? - Primarily, when full network connectivity cannot be guarantied across every instance as every Replication Server must be able to communicate to each other. - Optionally, Replication Servers and DIrectory Servers can be separated to optimize resource usage in large OUD topologies (10's of instances) - To enable external changelog service on a standalone OUD instance (for instance in a test environment) as a Replication Server is required is such case.


    Tuesday May 19, 2015

    Oracle Unified Directory 11gR2 PS3 available for download

    The Identity Management 11gR2 PS3 release, including OUD 11gR2 PS3 is available on eDelivery.  
    To download OUD, go to
    and select OUD 11gR2 PS3 

    R2PS3 documentation is available at

    Certification Matrix is available at

    Monday Feb 09, 2015

    How to lock every account in a LDAP subtree with OUD

    Let's assume a customer would like to lock every LDAP account in a given LDAP subtree stored in Oracle Unified Directory.
    An account can be locked by setting the ds-pwp-account-disabled operational to true in the accounts to lock. More about account lockout and password mpolicy is available at Managing password policies

    It is possible to assign the ds-pwp-account-disabled attribute to a set of accounts using virtual attributes.Virtual attributes are attribues whose values do not exist in persistent storage but are dynamically generated in some way.

    OUD Collective attribute is a mean to manage virtual attributes. More about collective attributes at using-collective-attributes '

    To lock every account in the oud=people,dc=example,dc=com subtree, create the following collective attribute:

    dn: cn=myattr,dc=example,dc=com
    objectclass: top
    objectClass: subentry
    objectClass: collectiveAttributeSubentry
    objectClass: extensibleObject
    ds-pwp-account-disabled;collective: true
    subtreespecification: {base "ou=people", minimum 1}
    collectiveConflictBehavior: virtual-overrides-real

    Thursday Jan 22, 2015

    ODSEE bundle patch available for download

    ODSEE Bundle Patch has been Released for Directory Server and Directory Proxy Server. (Doc ID 1962875.1)

    Search for Doc ID 1962875.1 in My Oracle Support for instructions.

    Wednesday Jan 21, 2015

    How to get OUD to start on Linux/UNIX boot

    To simplify integration of OUD with the target OS, you can use the create-rc-script command  to generate a shell script to start, stop, and restart the directory server. You can update the resulting script to suit the needs of your directory service. This command is available for UNIX or Linux systems.

    So you can use this command to create RC scripts e.g. run  sudo create-rc-script -f /etc/init.d/oud -u oud.

    Then run this script when the appropriate run level change on the target distribution. For instance, on OEL, run sudo chkconfig --level 3 oud on

    Make sure you use the -u userName option unless you really want to run OUD as root. 

    Wednesday Jan 14, 2015

    Configuring OUD to Support Multiple Enterprise User Security Domains

    Configuring OUD to Support Multiple Enterprise User Security Domains

    If your users and groups are stored in multiple domains, you must configure OUD to support multiple EUS domains. For example, a single OUD instance contains two EUS domains. One EUS domain stores users entries in Active Directory below cn=users,dc=ad1,dc=com. A second EUS domain stores user entries in a different Active Directory instance below cn=users,dc=ad2,dc=com. You must configure OUD to support each EUS domain.

    To configure OUD to support multiple EUS domains:

    1. Configure OUD as if the primary domain is the single domain containing all your users and groups.

      In this example, the primary domain is dc=ad1,dc=com.

      Complete the tasks in 28.4 Oracle Unified Directory Used as a Proxy Server for an External LDAP Directory with Enterprise User Security

    2. Configure the secondary domain.

      In this example, the secondary domain is dc=ad2,dc=com.

      For this secondary domain, complete the steps in User Identities in Microsoft Active Directory

    3. Create a new naming context for the EUS domain, which is dc=ad2,dc=com in this example.

      Complete the steps in to configure Enterprise User Security for an existing Oracle Unified Directory Proxy Server instance.

    4. Update the Oracle context with the new naming context.

      1. Create an LDIF file.

        In the following myconfig.ldif example, make the following substitutions:

        • Replace dc=ad1,dc=com with the DN of your first domain.

        • Replace orclcommonusersearchbase with the users location in the secondary domain.

        • orclcommongroupsearchbase with the groups location in the secondary domain.

        dn: cn=Common,cn=Products,cn=OracleContext,dc=ad1,dc=com
        changetype: modify
        add: orclcommonusersearchbase
        orclcommonusersearchbase: cn=users,dc=ad2,dc=com
        orclcommongroupsearchbase: cn=groups,dc=ad2,dc=com
      2. Update OUD configuration using the LDIF file you created in step 4a.

        ldapmodify -h oudhost -p 1389 -D "cn=directory manager" 
        -w password -f myconfig.ldif

    Wednesday Oct 22, 2014

    OUD and Referral Management with AD

    Oracle Unified Directory(OUD) can be configured as a proxy to Active Directory (AD).
    For instance, it is possible to define a Remote LDAP Extension in OUD pointging to Root Catalog of AD 2008.

    Searches to AD would return referrals, so the appropriate OUD Network group can to be modified to  follow referrals automatically with the command below:

    /dsconfig -h localhost -p 4444 -D "cn=directory manager" -j ~/.pwd  -X -n set-network-group-qos-policy-prop --group-name network-group --policy-type referral --set referral-policy:follow

    In some cases, a ldapsearch with a basedn which is not local to the root catalog still returns referrals to another AD Server. 
    OUD reports the following error: 

    SEARCH operation failed
    Result Code:  1 (Operations Error)
    Additional Information:  Unable to process the operation because a referral leading to an unknown or disabled ldap-server was received

    This error is specific to AD because AD builds referrals as follow: ldap://,DC=example,DC=com. does not systematically correspond to a LDAP host declared in the OUD proxy configuration. For security reasons, OUD follows referrals to hosts explicitely declared as LDAP server extensions in the OUD proxy configuration.

    To make sure OUD is able to chase referrals, define a new ldap-server-extension with remote-ldap-server-address property set to and remote-ldap-server-port set to 389. In this case, creation of a proxy workflow element is not required for this ldap-server-extension. More on ldap-server extensions at

    Friday Oct 17, 2014

    Troubleshooting OUD/EUS integration: Invalid username/password; logon denied

    Oracle's Enterprise User Security (EUS) enables you to store user identities in LDAP-compliant directory service for Oracle Database authentication.

    Enterprise User Security enables you to centrally manage database users across the enterprise. Enterprise users are created in LDAP-compliant directory service, and can be assigned roles and privileges across various enterprise databases registered with the directory.

    Users connect to Oracle Database by providing credentials that are stored in Oracle Unified Directory. The database executes LDAP search operations to query user specific authentication and authorization information.

    Here are steps to troubleshoot EUS when the "Invalid username/password; login denied" is reported to DB users by EUS:

    First, this error is reported in 2 cases:

    • the DB is not able to find a LDAP user that corresponds to the provided name on the DB side, 
    • the user password is invalid.
    Assuming the password is correct, follow the procedure below to identify the root cause:

    #1 Check EUS configuration

    The database reads its configuration from the entry cn=common,cn=products,cn=oraclecontext,$BASEDN:

    • The location of users and groups is configured in the attributes orclcommonusersearchbase and orclusercommongroupsearchbase. They are referred to as users and groups containers.
    • The username supplied to sqlplus must correspond to the value of orclcommonnicknameattribute in the user entry. For instance, if I connect to sqlplus using sqlplus joe/password, and orclcommonnicknameattribute=uid, then the database will look for an entry containing the attribute uid=joe.
    • The user entry DN must start with orclcommonnamingattribute. For instance, if orclcommonnamingattribute=cn, the user entry must be cn=joeuser,<orclcommonusersearchbase>.

    You can read the configuration using the following command:

    $ OracleUnifiedDirectory/bin/ldapsearch -h $LDAPSERVER -p $PORT -b cn=common,cn=products,cn=oraclecontext,$BASEDN  "(objectclass=*)" orclcommonusersearchbase orclcommongroupsearchbase orclcommonnicknameattribute orclcommonnamingattribute
    dn: cn=Common,cn=Products,cn=OracleContext,dc=eusovd,dc=com
    orclcommonusersearchbase: ou=people,dc=eusovd,dc=com
    orclcommongroupsearchbase: ou=groups,dc=eusovd,dc=com
    orclcommonnicknameattribute: uid
    orclcommonnamingattribute: cn

    #2 Check the User Entry

    You  must ensure that there is an LDAP entry in the user container that matches the username supplied by SQL+. Target LDAP entry must be an instance of inetorgperson and contain the attribute defined in orclcommonnicknameattribute:

    $ OracleUnifiedDirectory/bin/ldapsearch -h $LDAPSERVER -p $PORT -D $DN -w $PWD -b ou=people,$BASEDN  "(uid=joe)"                         
    dn: cn=joe,ou=people,dc=eusovd,dc=com
    userPassword: {SSHA}DdW5je5GCUnT2jVTeMdfPR9NWwkBt40FwWImpA==
    objectclass: person
    objectclass: organizationalPerson
    objectclass: inetorgperson
    objectclass: top
    uid: joe
    cn: joe
    sn: joe

    #3 Check the User-schema mappings

    If the user entry exists and can be read by the database entry, the problem can be that there is no user-schema mapping. EUS maps the LDAP user entry to a database schema following a mapping rule that is defined in Enterprise Manager console. The mapping associates either a user DN to a schema or all users of a subtree to a schema. It can be defined at the domain level or at the database level.

    #4 Check the global schema associated with the user

    If there is a user-schema mapping, ensure that the schema has the CONNECT privilege.

    The global schema was defined using the following commands:

    SQL> CREATE USER global_ident_schema_user IDENTIFIED GLOBALLY;
    User created.
    SQL> GRANT CONNECT TO global_ident_schema_user;

    Monday Oct 06, 2014

    Data Adaptation again

    Yet another common usage of OUD Transformations to transparently adapt some values during provisioning:

    In this real use case, ODIP (Oracle Directory Integration Platform) is used to synchronize some SQL tables with OUD.
    The country every user is living in is stored in an Oracle DB and is synchronized by DIP into the LDAP country attribute.
    Unfortunatelly, the country name format expected by the applications on the Directory side differ from the one used on the DB side.

    In this case, country name is stored in full in the DB (e.g. USA, FRANCE, ITALY) when apps that contact OUD expect standard country short form e.g. US, FR, IT.  For administrative and political reasons within the enterprise, it is not possible to create a additional mapping table in the RDBMS that could be used by a SQL JOIN to return the correct values.

    OUD Tranformation Framework can be used to address that integration problem: a so-called add inbound tranformation is invoked when a new entry is created and value mapping is applied on the incoming add request before it is processed by the OUD database engine. For sake of peformance, this transformation can be configured to trigger on udates originated from DIP only, using the network group mechanism.

    To create a transformation that maps USA to US and France to FR, do the following:

    First create the transformation with the appropriate mappings:

    dsconfig create-transformation \
    --set source-attribute:country=%country%(US,USA)(FR,France)(IT,Italy) \
    --type add-inbound-attribute \
    --transformation-name mapCountry \
    --set conflict-behavior:virtual-overrides-real 

    Then stash this transformation to a Transformation Workflow element to be inserted ahead of local DB (userRoot):

    dsconfig create-workflow-element \
              --set enabled:true \
              --set next-workflow-element:userRoot \
              --set transformation:mapCountry \
              --type transformations \
              --element-name mapCountry

    Then put the Transformation Workflow Element to the appropriate workflow so  that it can be invoked:

    dsconfig set-workflow-prop \
              --workflow-name userRoot1 \
              --set workflow-element:mapCountry

     At that stage, appropriate values are automatically stored in OUD.

    Thursday Oct 02, 2014

    Using OUD Transformations to expose Operational attributes as Regular ones

    Some (badly written) LDAP client applications expect to get operational attributes along with regular attributes when they search the directory w/o specifying attributes explicitely. The LDAP standards specify that operation attributes have to be explicitely requested in the search request. Alternatively, the special character + can be used to retrieve all the operational attributes w/o specifying explictely one by one.

    OUD adheres to the LDAP standard, so operational attributes must be explicitely specified in a search request.
    A specific option to facilitate migration from other directories can be used to expose schema related attributes (objectclasses, attributeTypes) as regular attributes. This option is described in one of my posts at

    However, others operational attributes are not exposed. Don't worry, OUD transformations framework can help you to solve this specific integration problem:

    Say you have an client application that expects the (operational)  pwdChangedTime attribute to be returned systematically as a user attribute.

    First, setup a OUD proxy. The client application in question will point to that proxy, but others applications will not be subject to the (non-standard) directory server behaviour.

    Then create a Add Outbound Transformation as below:

    dsconfig create-transformation \
              --set client-attribute:pwdChangedTime=%pwdChangedTime% \
              --type add-outbound-attribute \
              --transformation-name Mymap \ 

    Then put that transformation to a transformation workflow element:

    dsconfig create-workflow-element \
              --set enabled:true \
              --set next-workflow-element:userRoot\
              --set transformation:myMap \
              --type transformations \
              --element-name myTransfo \ 

    Insert your transformation workflow element to the appropriate workflow:

    dsconfig set-workflow-prop \
              --workflow-name workflow1 \
      --set workflow-element:myTransfo \ 

    Update the OUD Proxy schema, so that the pwdChangedTime is no longer declared as Operational. All you need to do is remove the  Usage DirectoryOperation and the NO-USER-MODICATION flag. Either modify the schema via LDAP or use the procedure below:

    stop the OUD proxy
    copy default schema
    cp <OUD_HOME>/config/schema/01-pwpolicy.ldif <OUD_PROXY_INSTANCE>/OUD/config/schema
    edit <OUD_PROXY_INSTANCE>/OUD/config/schema and change the pwdChangedTime definition as below:

     attributeTypes: ( NAME 'pwdChangedTime'
      DESC 'The time the password was last changed' EQUALITY generalizedTimeMatch
      ORDERING generalizedTimeOrderingMatch SYNTAX
      X-ORIGIN 'draft-behera-ldap-password-policy' )

    restart the OUD proxy

    At that stage, pwdChangedTime will be returned by a LDAP search with attribute list set to * or empty. 

    Wednesday Jul 23, 2014

    OUD R2PS2 Bundle Patch available

    The first bundle patch for OUD 11gR2PS2 ( is available for download from My Oracle Support.

    Search for the support note 1905631.1 (Doc ID 1905631.1 : Information And Bug Listing of Oracle Unified Directory Bundle Patches: (11gR2PS2))  that describes its content and download instructions (patch 18662903)


    My name is Sylvain Duloutre, I worked as a Software Architect in the Oracle Directory Integration Team, the customer-facing part of Directory Services & Identity Management Product Development, working on Technical Field Enablement and Solutions Architecture.

    The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

    A mirror of this blog is available on Wordpress here.


    « June 2016