Strange Brew

Following on to my previous posting , here is a logstash configuration that collects logs from both OpenAM and OpenIDM, and feeds them into elastic search: input { file { type => idmRecon start_position => beginning path => "/opt/openidm/audit/recon.csv" } file { type => idmActivity start_position => beginning path => "/opt/openidm/audit/activity.csv" } file { type => amAccess # start_position => beginning path => "/opt/openam/openam-config/openam/log/amAuthentication.*" } } filter { if [type] == "idmRecon" { csv { columns => [ "idX","action","actionId","ambiguousTargetObjectIds","entryType","message","reconciling","reconId", "rootActionId","situation","so...

Logstash is a general purpose log collector that can read, transform and collect various logs. The following logstash configuration will collect OpenAM Access logs. The default target here is Elastic Search - which is document oriented no-sql database optimized for text search (perfect for log files). In a future blog I will show you how you can use Kibana to makes some sexy charts of your access data. file { type => amAccess start_position => beginning path => "/path_to_your_install/openam/openam/log/amAuthentication.access" } } filter { if [type] == "amAccess" { csv { columns => [time,Data,LoginID,ContextID, IPAddr, LogLevel, Domain, LoggedBy, MessageID, ModuleName, NameID, HostName] separator => " " } date { match => ["dateTime", "yyyy-MM-dd HH:mm:ss"] } geoip { datab...

CoreOS  is new minimal Linux based OS designed to run applications in containers.  The design concept is similar to Joyent's SmartOS  (aside: I would love to see the CoreOS team adopt ZFS. It has so many compelling features for hosting containers. But I digress...) CoreOS uses Docker  lightweight containers, which are in turn based on Linux LXC containers. You will want to check out the excellent getting started guide , but the readers digest summary is that Docker containers are built up incrementally and inherit from their parent containers.  Each new container contains only the deltas from the parent - making it possible to distribute a small incremental feature set. When you run a Docker container, you are running only the processes that are needed for your service (for example, OpenDJ). You are not running an entire copy of the OS, making these containers super lightweight (OpenSolaris fans have had this feature for years in the form of zones...

ForgeRock 's   Open Identity Gateway (OpenIG) is a "smart" reverse proxy interacts with the HTTP session to modify headers, cookies, and the body. A common OpenIG  use case is to SSO enable legacy applications that can not be modified to use a policy agent. The way this works is described in the gateway guide  but the readers digest version is: OpenIG itself is protected with an OpenAM policy agent OpenAM's password capture post authentication handler is configured to capture the user's password on login, and provide it (encrypted) to OpenIG.  OpenIG is configured to watch for an HTTP request to the legacy application's login page When OpenIG sees the login page it injects the users credentials into the login flow.  The guide has a few examples for Wordpress login - but I wanted to demonstrate login to Tomcat.  This OpenIG config.json file is configured to SSO into the sample form login demo that included with tomcat (/examples/jsp/s...

Let's talk about a very cool OpenIDM feature called custom endpoints . If you have used OpenIDM you know that objects in the system (be they repository, provisioner, or configuration objects) are available at  RESTful endpoints that accept and return JSON representations. This makes OpenIDM super easy to integrate with and script. For example, if you add an LDAP adapter called "ldap", a REST endpoint becomes available at /openidm/system/ldap/ that allows you to query, read, write, update and delete LDAP entries.    As an aside, most OpenIDM configuration objects are dynamically reloaded when they are modified. This makes development a joy as you do not need to bounce the Felix OSGI container every time you make a change.  The container starts very fast (30 seconds or so on my laptop) - but every second counts! What you might not know is that you can easily add your own custom endpoints. A custom endpoint is an OpenIDM script that accepts a REST r...

Out of the box OpenIDM uses a local "openidm-admin" account to perform RESTful authentication. This is fine for testing, but for production you probably want to maintain control over the admin accounts in your directory. This  wiki entry  will show you how to configure pass through authentication to LDAP. This will allow you to maintain the OpenIDM administrative accounts used for RESTful access in your directory.  You simply add these accounts to the LDAP group specified in the configuration. Check out the wiki for the full story.

Tl;DR: Want to install the complete ForgeRock Open Identity Stack in 20 minutes? This is for you. You already know that the ForgeRock OIS stack (OpenAM, OpenIDM and OpenDJ) is super easy to install.  Using Ansible and Vagrant we can make the process even faster! From start to finish takes approx. 20 minutes (automated, hands off) to install a Centos image running  the following: haproxy to route ports 80/443 to various backend services apache instance running on port 1080  OpenIDM running on port 9090 (available at http://openam.example.com/openidm ) OpenDJ running on port 389. This is the user store for OpenAM. OpenAM running on port 8080 (available at https://openam.example.com/openam ) A tomcat "application" instance on port 18080 (For future sample application hosting). /etc/init.d scripts to start OpenAM, OpenDJ, Apache etc. This project  https://github.com/wstrange/frstack includes everything you need to get started. Next steps: ...