For those about to Rock! … introducing the ForgeRock Identity stack introductory bootstrap “sequester special”

I am offering an introductory special to ForgeRock’s Identity (I3) Stack.  I am calling this the “Sequester Special”. The Federales are cutting back budgets and furloughing the Air Traffic controllers (cough … why not the TSA agents at the airport instead) but this is your chance to capitalize on that.

So what’s this all about?

You get to try out the  ForgeRock Open Identity Stack (**ForgeRock support license required for binaries used in a production environment**) and you get a  reduced rate on professional services … to ease those sequester blues.

Download the information sheet here.

Sequester Special | For those about to ROCK …

ForgeRock Open Identity (I3) Stack Bootstrap Package

Tumy-Tech’s Professional Services team provides services to assist you in successfully and rapidly implementing ForgeRock’s Open Identity (I3) Stack into your environment.  The end result? A working implementation of ForgeRock’s Open Identity Stack designed to introduce you to ForgeRock’s products as well as demonstrate several common configurations requested by your many customers.

The ForgeRock Bootstrap Package Includes:

  • ForgeRock Open Identity (I3) Stack installation 
  • User Identity Reconciliation from enterprise LDAP (or AD)
  • User Provisioning & Single Sign-On (SSO) to Google Apps
  • Just-In-Time (JIT) Provisioning & SSO to Salesforce.com
  • Customized Installation & Configuration Documentation


Components Included:

  • OpenDJ
  • OpenIDM
  • OpenAM

Customer Requirements:

  • Customer provided servers must meet ForgeRock product specifications.
  • Customer must have an existing Google Apps for Business (or Education) account.
  • Customer must have an existing Salesforce.com account (or developer.force.com).
  • Customer installation environment must have internet connection.
  • Cost does not include travel expenses. (Remote installations are recommended; however, we can provide on-site service if you prefer.  All travel expenses will be invoiced to customer.)


Disclaimers (the small print):

  • Use of ForgeRock binaries, in production, require a license and subscription from ForgeRock.
  • Each product will be installed on up to one server in customer’s environment.
  • Tumy-Tech will use the most up-to-date, stable build publicly available.
  • OpenIDM will be configured to reconcile users from one existing LDAP (AD or LDAP) user store with up to 20 attributes mapped.
  • Typical bootstrap setup time: 2-3 days. (Additional requirements / use cases are welcome but may require additional time and cost.)

Call or Email our sales team, today, to schedule (240.215.4825 / info@tumy-tech.com)


Open Source Identity Solutions

I was asked by a colleague today to provide sources of analysis comparing Open Source IDM Solutions. I think they were looking for comparisons to closed source solutions but there is not a lot of that out there. I provided the following list as a starting point.

I generally like to save time (avoid searching for this again in the future) so I decided to put what I found here. If I am missing anything please let me know and I will update the list.

Provisioning/User Identity Management:


SSO/Access Management/Authentication:


Directory Services:


SAML IDP with multiple inbound URLs? possible? #SAML #IDM #identity #infosec

I had an interesting use case come up this morning and I am wondering if there are any “federation” products that can handle this use case.  My client would like to configure the IDP to handle different sets of users (let’s call them “internal” and “external”).  To avoid the external users from being redirected to the IDP directly it has been front-ended with a proxy (Apache HTTP) located in the DMZ.  Internal users should have access to the same same SPs … but probably don’t want the internal users getting redirected to the proxy located in the DMZ.  One of the products that I work with can only have one “server url” configured (that I know of) … do other products allow for multiple URL’s to be configured?  Would love to hear if this is actually a “problem” and if so how other vendors have implemented.  The easy solution on our part is to deploy another federation server (IDP) to handle the different users … personally I hate to keep telling the customer to deploy a new instance each time a new use case comes up.  I don’t think that scales very well.

Implementing #OpenID with Oracle Identity Federation #Identity #OIF

I have a customer that is an Oracle Identity Management shop. They are looking to leverage OpenID to increase the ease of collaborating with internal and external partners as well as to reduce the cost of managing passwords for non-employees. They are also implementing other strategies to reduce the use of passwords in their environment, but for today I just want to talk about how to implement OpenID.

A good starting point is Warren Strange’s (Strange Brew) “Adding an OpenID Relying Party to Oracle Identity Federation (OIF)”. In this post Warren describes, in perfect detail, how to integrate OIF with Google as your Identity Provider. As Warren points out, OIF includes a test service provider integration module that you can use to validate that you have things configured correctly. You will have to change to use another Service Provider Integration Module (OSSO, OAM or Custom) to actually leverage this in production; otherwise the user will always end up on the test results page regardless of where they were attempting to get to.

The other side to the coin is adding an OpenID Identity Provider to Oracle Identity Federation. In my customer’s use case they have internal organizations that would like to consume identity information, from my customer, but they still want to remain loosely coupled. Their choice here would be to go with SAML or OpenID. They will be supporting both options.

First, make sure that you are on at least OIF

To enable OIF as an OpenID IdP you need to log into Enterprise Manager and go to Oracle Identity Federation >> Administration >> Identity Provider. Make sure that the Identity Provider is enabled in the Common tab, Apply (if not already enabled) and then switch to the OpenID 2.0 tab. From this tab, make sure to check Enable OpenID 2.0 Protocol then at the bottom of the screen click on the box that says Create, which is next to “Generic OpenID Service Provider”. This provides configuration for service providers that are not specifically named in the Federation. Click Apply.

Next, go to Oracle Identity Federation >> Administration >> Federations. You should see to Trusted Providers already listed. The first will have a Provider-ID of “Unknown-OpenID-RP”, which was created when you created the generic provider in the step before. The second, which will be there if you followed the steps in Warren’s blog, will have a Provider-ID of “Google” (or something like that). You will need to add a provider for your IDP. Click on “Add” and the “Add Trusted Provider” screen will open. Click the radio button next to “Add Provider Manually”. Let’s assume that we are implementing this for a company called Acme, Inc.

Complete the information as shown below, and then click “OK”.

Next, highlight the Provider you just created and click on “Edit”.

In the Trusted Provider Settings tab add the Endpoint URL and the Discovery URL:

Endpoint URL: http://fed.acme.com:7777/fed/idp

Discover URL: http://fed/acme.com:7777/fed/idp

Then, click on the Oracle Identity Federation Settings tab.

To enable a setting you have to click on the little square in the circle until it turns blue and then check the box at the end of the line. You want to enable both Map User via Federated Identity and Error when User Mapping fails. Your screen should then look like this:

Click Apply.

Optionally, you can enable the Attribute Exchange by clicking “Edit” next to Attribute Mappings and Filters.

The last thing you need to confirm that your Identity Provider has a user identity store that it will authenticate against. You can do this by clicking on Oracle Identity Federation >> Administration >> Authentication Engines. The Default Authentication Engine will be set for whatever you selected during install. The default is JAAS. I changed mine to LDAP Directory. Then click on the LDAP Directory tab. Click Enable Authentication Engine and complete the requested information. Make sure you test the LDAP connection before applying.

At this point you can test using the same steps that Warren outlined in his blog post:

Go to: http://fed.acme.com:7777/fed/user/testspsso

Select ACME from the IdP Provider ID drop-down box.

Then click on Start SSO. You should be prompted by OIF’s default IDP to authenticate

and then after successfully authenticating you will have to Accept on a User Consent page and

then you will be returned to status page showing you a successful authentication.

So, those are the basic steps. There are a number of use cases that would require additional configuration. For Federal agencies implementing this for a FICAM solution you would need to look at enabling the Provider Authentication Policy Extension (PAPE) 1.0 options on the Identity Provider configuration page.

About TUMY | Technology, Inc.
TUMY | technology, inc. (TTi) provides Identity & Access Management (IAM) solutions that secure and manage digital identities and applications.
In response to growing security threats and regulatory compliance mandates (HIPAA, Sarbanes-Oxley, etc.) organizations need solutions that can be implemented quickly to identify users and their entitlements before giving access to requested resources. We specialize in vendor solutions such as ForgeRock and Oracle. Our mission is to deliver secure, robust and cost-effective solutions to our clients. Please contact us at: info “at” tumy-tech.com or

Federal #ICAM “Reading List” #IDM #Identity

I have had a number of conversations over the last few weeks regarding ICAM, which is the U.S. Government’s Identity, Credentialing, and Access Management initiative. Essentially, these are a set of guidelines, frameworks and specifications to assist Federal agencies in implementing Identity and Access Management. I have had my own library that I often refer to and I thought it would be good to share these links here:

Key points from #M-11-11 (#HSPD12 and #ICAM)

I just finished reading through the newly released M-11-11, “Continued Implementation of Homeland Security Presidential Directive (HSPD) 12 – Policy for a  Common Identification Standard for Federal Employees and Contractors“.

Disclaimer: The following is my interpretation of M-11-11 … I have no authority or influence over actual requirements.  My opinions, interpretations or recommendations in no way constitute official guidance.  Please refer to the official documentation for official guidance.

That being said, here are a few key points:

  • By February 25, 2011 – Agencies SHOULD designate a lead official for ensuring the issuance of they agency’s HSPD-12 implementation policy.
  • By March 31, 2011 – Each Agency SHOULD develop and issue an implementation policy, through which the agency will require the use of PIV as the common means of authentication.
  • Effective immediately (February 3, 2011) – All new systems under development MUST be PIV enabled (according to NIST guidelines) prior to becoming operational
  • Effective beginning of FY2012 (October 2011) – All existing physical and logical access control systems MUST be upgraded to use PIV (according to NIST guidelines), prior to using funds to complete other activities.
  • Procurements for services and products, involving facility (PACS) or system access (LACS) MUST be in accordance with HSPD-12 and the Federal Acquisition Regulation.
  • Agency processes MUST accept and electronically verify PIV credentials issued by other federal agencies.
  • The government-wide architecture and completion of agency transition plans MUST align (as described in the Federal CIO Council’s “Federal Identity, Credential and Access Management Roadmap and Implementation Guidance

Basically what this is saying is now that the majority of the federal workforce has been issued HSPD-12 cards it’s time to starting utilizing them.  I am currently working with one Federal agency to develop their architecture to implement support for the requirements in this memo.   I would be more than happy to talk shop with anyone that is interested.

Nishant Kaushik, from Oracle has provided slides that explain Oracle’s IDM product suite and how it addresses the Federal ICAM requirements.  I suggest taking a look at that.  Additionally, Anil John (JHU) is doing a lot of research on the Federal ICAM initiatives.  He has done a lot of great work and blogged about it.