Tumy | Tech is hiring a Senior IDM Lead

We have an opening on one of our current projects for a Senior Technical Lead.  This person will assume the role of technical lead with one of our customer’s projects where we are deploying ForgeRock’s Open Identity Platform.

Senior Technical IAM Lead Architect/Engineer:

Tumy | Tech is seeking a senior IAM Technical Lead with at least 8 years of designing and implementing Identity and Access Management systems. Although we primarily work with ForgeRock’s Open Identity Platform (OpenAM, OpenIDM, OpenDJ, OpenIG), we are looking for candidates with experience in any IAM platform (e.g. Oracle, CA, IBM, PingIdentity).

This position is for a senior technical lead within our IAM group for an existing customer project. This role will focus on building and implementing Identity and Access Management (IAM) strategies and services. This position is key to enabling a modern authentication and authorization enterprise systems. As a lead, this role will be responsible for collaborating amongst several organizations within the customer’s enterprise.

This position also has lead responsibilities for the production support of the IAM infrastructure including the development, administration and operations. This role is responsible for coordinating changes, reviewing strategies of various members of the team and advising them on execution.

Key Duties and responsibilities

* Plan and deliver the technical implementation of key IAM enterprise system
* Enable SSO, REST-based authentication
* Troubleshoot errors and issues within the IAM deployment
* Collaborate with various project teams to deliver key programs
* Participate in on-call responsibilities
* Implement change-control and configuration management best practices
* Lead the execution of project deliverables

Relevant Technical Skills

* Solid understanding of modern open source or commercial IAM systems
* Solid understanding of UNIX/Linux operating systems
* Solid understanding of common monitoring and auditing tools
* Solid understanding of PKI
* Strong experience with multi-factor and adaptive authentication
* Solid understanding of network protocols, Firewalls, Load Balancers configurations
* Solid understanding of Cloud architectures (AWS / GCP)
* Solid understanding of Agile and DevOps methodologies for deploying Infrastructures and Applications

Significant experience / knowledge of the following

* Strong experience with Web-based Access Management Systems
* Strong experience with REST-based protocols
* Strong experience with ForgeRock’s Open Identity Platform
* Expert knowledge with Single-Sign-On authentication
* Expert knowledge with major LDAP platforms (e.g. DSEE, OpenDJ, OID, etc)

Other Relevant Skills/Experience

We’d like to hear about your experience in any of the following technologies:

* Federation Technologies (SAML, OpenID Connect, OAUTH2)
* J2EE
* Web Application Development
* Web Application Security
* JavaScript/Groovy
* Business Process Model Notation (BPMN)
* Directory Services (LDAP, AD)
* DevOps
* Automation / Orchestration (Puppet, Chef, JuJu)
* Cloud Deployment Architecture (e.g. AWS)
* Docker

TUMY | TECH is an Equal Employment Opportunity (EEO) employer and gives consideration for employment to qualified applicants without regard to race/color/age/religion/sex/sexual orientation/gender identity/national origin/disability/protected veteran status, or genetic information.

Important to note: While we do normally hire with C2C and 1099 relationships, for this position we require the technical lead to be a W2 employee with Tumy|Tech.

If you are interested in this role, please reach us through our contact page or email: careers at tumy-tech.com

Principals Only Please.

OpenAM v.13 – REST STS OpenAM Token Translation

A quick demo of OpenAM’s Token Translation Service

According to Wikipedia:

In a typical usage scenario, a client requests access to a secure software application, often called a relying party. Instead of the application authenticating the client, the client is redirected to an STS. The STS authenticates the client and issues a security token. Finally, the client is redirected back to the relying party where it presents the security token. The token is the data record in which claims are packed, and is protected from manipulation with strong cryptography. The software application verifies that the token originated from an STS trusted by it, and then makes authorization decisions accordingly. The token is creating a chain of trust between the STS and the software application consuming the claims. This process is illustrated in the Security Assertion Markup Language (SAML) use case, demonstrating how single sign-on can be used to access web services.

Here is a quick video (w/o audio) demonstrating how to create an STS instance in OpenAM v.13 and then using Postman (REST client) to translate the tokenid of an authenticated user.

Caveat: There are obviously more configuration requirements for an actual deployment, the ACS URL would be key, for example. Refer to the STS documentation linked below the video.


REST Requests:

POST /openam/json/authenticate HTTP/1.1
Host: am.example.com:8080
X-OpenAM-Username: username
X-OpenAM-Password: password
Content-Type: application/json
Cache-Control: no-cache


POST /openam/rest-sts/sts-test?_action=translate HTTP/1.1
Host: am.example.com:8080
Content-Type: application/json
Cache-Control: no-cache

“input_token_state”: {
“token_type”: “OPENAM”,
“session_id”: “AQIC5wM2LY4SfczD8y5-kVgiXY7rxxxxxxxxx8k0o8.*AAJTSQACMDEAAlNLABQtNjY4MzQxNjkzMDg2ODI1MjIzOQACUzEAAA..*”
“output_token_state”: {
“token_type”: “SAML2”,
“subject_confirmation”: “BEARER”

Next Steps?
We implement solutions like this for our clients nearly every day. Are you looking for assistance on a current project? Maybe you have a future project and you just want to keep in touch. Awesome! Head on over to our contact page and drop us a line. We’re looking forward to hearing from you.

ForgeRock upgrades entire stack today! #OpenAM #OpenIDM #OpenDJ #OpenIG

ok guys … ForgeRock released updates across the board today:

  • Access Management – AM 13
  • Identity Management – IDM 4
  • Directory Services – DJ 3
  • Identity Gateway – IG 4
  • I have only had a chance to go through the OpenAM release notes … and this is a big release for OpenAM. Clearly a ton of effort was put into this version. Check out the release notes for a comprehensive list of new features. I have highlighted my favorites here:

  • Contextual Authorization
  • SAML 2 Authentication Module
  • OAuth 2.0 Device Flow
  • Additional UMA Support (you knew this was coming)
  • OAuth 2.0 Enhancements
  • Elasticity and Scaling Features (Stateless Sessions and Dynamic Configuration, Yay!!)
  • Soap STS is back … so, you have REST and SOAP STS services now
  • OpenIG to replace DAS (bye-bye DAS … you won’t be missed, along with your little friend JATO too)
  • One more – listed under “User Experience Enhancements” there is a new one “Recording Troubleshooting Information” – I don’t know much about this and need to find out some more but looks really useful
  • So, go download these new versions and check out this new stuff. Let me know if you find new stuff that I haven’t found yet.

    OpenAM: Forcing users to reset password on next login.


    A very common use case, when implementing ForgeRock’s OpenAM, is forcing a user to reset their password the next time they login. Seems easy enough right? … next time a particular user authenticates in they should be prompted to change their password before continuing on to the resource (web page) that they had originally requested.

    The documentation does mention a setting, in section 8.3, to enable this:

    Force Change Password on Next Login

    When enabled, the user must change her password next time she logs in after OpenAM resets her password.


    Unfortunately, this doesn’t seem to work. Doing a little “googling” you can find there is an open bug on this.

    There are several places online where ForgeRock’s Peter Major (aka @aldaris) recommends implementing this at the directory server layer instead. This is pretty easy to implement if you are using OpenDJ as your user identity repository.

    I am going to explain how to configure this here:


    In OpenAM your authenication module needs to be set to LDAP instead of DataStore. The default ldapService authentication module uses the DataStore authentication module, which does not support forcing a user to reset their password. Instead you shoud create a new authentication chain which uses LDAP as the authentication module.

    : I am assuming that your LDAP authentication module is configured to use an OpenDJ instance.


    There are two settings in OpenDJ which need to be enabled.

    1. Modify the Password Policy to enforce Password Reset on Next Login
    2. Enable pwdReset attribute on the user’s record

    Modify the Password Policy:
    Using OpenDJ’s dsconfig command line tool you can edit the user’s password policy to enable the Password Reset settings. In this example the user’s password policy is the Default Password Policy. Change the setting force-change-on-reset from false to true. (Note: in production you probably would have created a different policy and wouldn’t be using the default policy)

    Enable pwdReset attribute on the user’s record:
    This setting can be changed either via an ldap browser, command line (ldapmodify) or even by using a provisioning tool like OpenIDM. Keep in mind that this is considered an operational attribute so you’ll need to ensure that you have permission to change the value.

    Note: The embedded OpenDJ instance that comes with OpenAM is configured to prevent a user from changing their password so you will likely run into errors unless you have modified the ACI. It’s actually not recommended to use the embedded OpenDJ instance as a user identity store, in production. So, use an external instance of OpenDJ and you’ll be fine.

    So, let’s see this in action:

    by the way … this works just fine using the XUI as well:

    Wrap up

    So, we’ve demonstrated how easy it is to implement the force password reset on next login functionality. We’ve validated that this approach works whether you are using the legacy UI or the new modern XUI.

    Don’t hesitate to reach out if you have any questions. If you need help implementing OpenAM or any other product’s in ForgeRock’s Open Identity Suite drop us a line through our contact page.

    Resetting Forgotten Passwords with @ForgeRock #OpenAM

    Implementing the “Resetting Forgotten Passwords” functionality as described in the OpenAM Developer’s Guide requires some additional custom code.

    It’s pretty straight forward to implement this functionality and can be done in 4 steps (per the Developer’s Guide):

    1. Configure the Email Service
    2. Perform an HTTP Post with the user’s id
    3. OpenAM looks up email address (based on user id) and sends an email with a link to reset the password
    4. Intercept the HTTP GET request to this URL when the user clicks the link.

    All of this functionality is available out of the box with the exception of #4.  I wrote some really simple javascript that can be deployed to the OpenAM server that will handle this.  This code was written as a proof-of-concept and doesn’t include any data-validation or error handling but that could be added fairly easily.  This script can be deployed to the root directory of your OpenAM deployment.  Just be sure to update the Forgot Password Confirmation Email URL in the OpenAM Console under Configuration > Global > REST Security.

    I have made the code available on my GitHub page and you are welcome to use it or modify it.

    As described on the README:

    • These files are a proof of concept to extend OpenAM’s REST-based password reset functionalit
    • Add these two files to your OpenAM deployment root (e.g. /tomcat7/webapps/openam
    • Modify the server urls to the appropriate servers in your environmet
    • Change the REST Security settings in the OpenAM console (e.g. http://[AM server and port]/openam/forgotPassword.jsp)

    The file resetPassword.jsp is an optional file that will display a field for the user to provide their id and will then POST to /json/users?_action=forgotPassword (Step #2 from the Developer’s Guide).


    Thanks to @Aldaris and @ScottHeger for providing advice while I was working on this.

    Seeking Senior OpenAM Engineers

    A client of mine has asked me to assist them in finding a full-time Senior OpenAM Engineer.  They are a startup, based in Northern, Virginia.  They are working on some pretty cool initiatives with OAUTH2 and SAML and need an experienced engineer to lead this effort. 

    If you are interested in this please feel free to reach out to me and I’ll put you in touch.

    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)

    Extending OpenAM Policy Service to support additional actions

    I am wrapping a crazy busy week.  Probably one of my most technically in-depth week in a really long time.  So what kept me busy?  Deep-diving into OpenAM’s Entitlement’s engine, learning about it’s REST interfaces and how to extend OpenAM to leverage custom service types.  I’ll explain later since I know your thinking, “Tumy … dude, what the heck is a service type?”.

    Alright, let’s jump into it …

    Entitlements are policies or rules that state what you (or any user) can and can’t do.  Sounds simple right?  In Information Security entitlements usually define what resources a user can access, how they can access it, when they can access it and so on and so on.   A resource can be a web url, a banking transaction, a database record, or frankly anything you might want to protect.  Typically entitlements are expressed through XACML http://en.wikipedia.org/wiki/XACML.  Entitlements are used in access control settings and used to define fine-grained authorization rules.    This is starting to become too much of a Entitlements 101 class so let me just jump into the hand’s on stuff.

    Ok, Forgerock … in their OpenAM product they have an Entitlements engine which is essentially a Policy Management Point and a Policy Decision Point (Google is your friend if you don’t know what those things are).  Out of the box OpenAM supports a few different “service types” which are essentially a set of resources and their associated actions.  For example a web url would potentially have the actions of “GET” and “POST”.  There are a couple of other service types too (a banking example and a few others).  But what happens when our resource is not a web URL and we want to have actions besides “GET” or “POST”.  What we if we wanted to have a resources defined as database table names and we wanted to have actions such as “READ”, “UPDATE”, “DELETE”.  (Update:  Starting in OpenAM Version 11.2 some of these additional actions are available out of the box) We want to be able to create rules that we can either allow a user to read information from a specific table or deny their ability to read from a certain table.  Ok, hopefully you get the idea … if you don’t email me and we can talk about it.  OpenAM has a great set of command line tools that you can use to interface with the product, these tools have also been “web” enabled on a jsp page which is accessible through the admin console (it’s disabled by default though).

    To create this new service type there are a few steps we need to take:

    • Create a custom Application Type
    • Create a custom Service Type
    • Create a custom Application
    • Create the policy, using the custom service type

    4 easy steps.

    The Custom Application Type is a few lines that get imported.  Let’s assume that you have enabled the web ssoadmin.jsp and have accessed it here:


    You would see a page like this:


    Do a quick search for “create-appl-type” and you then click on it.

    Fill in the form that is displayed with this information:

    Application Type Name: BTPoliyService

    This creates the set of actions that will be available for your resources of this type.  Save that and then you need to create the Custom Service Type.  This is created by modifying an XML file and then importing that file into a form that is similar to the one we just saw.
    The service type provides a little more detail on the actions and sets the True/False values that will be displayed in the policy manager.

    <?xml version=”1.0″ encoding=”UTF-8″?>DOCTYPE ServicesConfiguration SYSTEM “jar://com/sun/identity/sm/sms.dtd”>

    <Schema serviceHierarchy=”/DSAMEConfig/BTPolicyService” i18nFileName=”BTPolicyService” i18nKey=”BTPolicyService”>
    <AttributeSchema name=”serviceObjectClasses” type=”list” syntax=”string” i18nKey=”BTPolicyService”/>
    <AttributeSchema i18nKey=”READ” name=”READ” syntax=”boolean” type=”single” uitype=”radio” >
    <AttributeSchema i18nKey=”DELETE” name=”DELETE” syntax=”boolean” type=”single” uitype=”radio” >
    <AttributeSchema i18nKey=”UPDATE” name=”UPDATE” syntax=”boolean” type=”single” uitype=”radio” >
    <AttributeSchema i18nKey=”ADD-ACCESS” name=”ADD-ACCESS” syntax=”boolean” type=”single” uitype=”radio” >

    In the above XML file, you should notice there are several spots where I have provided the name of the service “DatabaseTablePolicyService” and then the actions and their True/False values. In the ssoadm.jsp search for “create-svc” and then copy and paste this file into that form.

    Next step and last step of the “extending” part of the process. So, in the ssoadm.jsp web page, search for “create-appl”. Click on this link and it will open a form very similar to the “create-appl-type” form. Enter the following information:

    resources= table://*

    Notice in the above file, that I add the application name and it matches the name we have used in the other configurations. I added the actions again and finally I actually define a resource. I personally like to describe the resource type in a URL style … I can use “table://” as my resource in the policy and that will help remind me later what type of resource that is. You don’t have to prefix your resources in your policy with that … it seems to be optional.

    At this point you can jump back over to the OpenAM Admin console and create a policy based on this resource, as you can see in the following screenshot.

    Screen Shot 2012-12-15 at 11.27.07 PM

    So, that’s pretty cool stuff … The entitlements engine is pretty robust, it’s fast and … it has a RESTful interface. I am going to do a deep-dive blog post on the RESTful services at some point but for now let’s just take a look at how you can evaluate an entitlement.

    Evaluating a Privilege:

    * ssoToken = Authenticated User’s Token
    * iPlanetDirectoryPro = session cookie … admin users session token
    * action = action user is attempting (GET, POST, READ, DELETE, etc)
    * application = application type of policy (defaults to iPlanetAMWebAgentService)
    * Subject (user attempting action … encoded session token)

    curl -v -H “X-Query-Parameters: ssotoken:AQIC5wM2LY4SfczpL5a3M02ju3uyOd6iMj4zZvPZXB3BNQ4.*AAJTSQACMDE.*” -b “iPlanetDirectoryPro=”AQIC5wM2LY4SfcxcPg_yUwYu-iQPHH663tv9AnoEEr6j_2k.*AAJTSQACMDE.*”” “http://am.host:port/openam/ws/1/entitlement/entitlement?action=READ&resource=table://my_table_name&application=BTPolicyService&subject=4l18suAL/hXNCfzykwIlbV0WbtM%3D”

    This will return a JSON formatted object:

    “actionsValues”:{READ:”true”, UPDATE:”false”, DELETE:”true”, ADD-ACCESS:”false”},

    You can create a policy that would return attributes, from the user’s identity record, along with this JSON object. There are also RESTful services that will just return an allow or deny, which is great if you don’t need as much information back.

    So, that was real high level and really basic but I hope that I gave you some ideas for the potential of this engine. Let me know if you have any questions or want to chat about. Also, I am available on a consulting basis to help design or implement this in your environment.


    • There were a bunch of people at ForgeRock that help me out at various points through this.  You guys know who you are … I’ll leave your names out so that you don’t get bombarded with requests.
    • Also, there were a few non-ForgeRock guys that went through this last year and gave me some pointers along the way.  Thanks!
    • And finally … to the guys that did this first at Sun.  Thanks for building this stuff and documenting it.  I am thankful that those web pages that you created haven’t vanished yet.

    OpenAM: Protecting a Web Application

    In response to a post that I had written before on how to install OpenDJ and OpenAM I had someone remind me that I never came back and wrote the follow on post (which I had promised to do).  They posted the question to my other blog site (which I have since migrated over to this site).  I am going to answer the question here as this is the only blog that I am presently maintaining.


    Can you paste me the link which talks about next part of the installation.
    1. Configure OpenAM to look to OpenDJ for users
    2. Install a Web agent
    3. Create an Access Policy to protect a web application.

    I often say that I am successful by “standing on the shoulders of giants”.  There is so much great “how to” content on the ForgeRock Community wiki site and that is where I turn to when I am looking for help or advice on OpenAM, OpenDJ and OpenIDM. Take a look at the section, “OpenAM: How do I?”.  There are a number of “how-to” articles that are literally step by step with screen shots.  

    The link for the article that specifically talks about how to configure OpenAM to protect a web application can be found here:  Add Authentication to a Website using OpenAM.

    ******** Shameless Plug Alert ************

    To protect a single web site is pretty simple and straight forward but sometimes you have unusual or difficult use cases where you need another set of eyes or additional help architecting your solution.  I have a lot of experience with the ForgeRock suite and I am available to provide consulting services.  Please don’t hesitate to reach out if you are interested in contracting my services.

    OpenDJ & OpenAM automatic startup on Ubuntu

    I have been installing the ForgeRock stack on Ubuntu a lot lately.  One of the things that I noticed is that when configuring OpenAM and OpenDJ for automatic startup you need to let OpenDJ finish starting up before starting Tomcat (OpenAM) … otherwise OpenAM will not be able to find it’s configuration and assume that it’s a new install.  I added a timer to the start up script to make the script sleep for a minute before starting (YMMV) Mark Craig (from ForgeRock) clued me into a nice little bit of code “start on started opendj” essentially this tells the startup script to wait until opendj has started before starting Tomcat.  Thanks Mark, that’s exactly what I was looking for.


    cd [install dir]/opendj/bin

    sudo ./create-rc-script -f /etc/init.d/opendj -u [user to run as]

    cd /etc/init.d

    sudo update-rc.d opendj defaults

    OpenAM [on Tomcat]

    sudo vi /etc/init.d/tomcat

    Now paste the following content:

        # Tomcat auto-start
        # description: Auto-starts tomcat
        # start tomcat with user: ubuntu
        # pidfile: /var/run/tomcat.pid
        export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64
        case $1 in
                start on started opendj
                /bin/su ubuntu /opt/tomcat/bin/startup.sh
                /bin/su ubuntu /opt/tomcat/bin/shutdown.sh
                /bin/su ubuntu /opt/tomcat/bin/shutdown.sh
                /bin/su ubuntu /opt/tomcat/bin/startup.sh
        exit 0

    Make the script executable by running the chmod command:

    sudo chmod 755 /etc/init.d/tomcat

    The last step is linking this script to the startup folders with a symbolic link. Run the following two commands:.

    sudo ln -s /etc/init.d/tomcat /etc/rc1.d/K99tomcat

    sudo ln -s /etc/init.d/tomcat /etc/rc2.d/S99tomcat

    Restart the system and tomcat will start automatically.