2H2019 Identity Management Funding Analysis

Back in July, I wrote an article taking a brief look at venture capitalist funding patterns within the identity and access management space, for the first half of 2019.  I am going to revisit that topic, but for the second half of the year.

Key Facts July to December 2017 / 2018 / 2019

Funding increased 309% year on year for the second half of 2019, compared to the same period in 2018.  Taking a 3 year look, it seems, that perhaps 2018, and not 2019, was the unusual year.


The number of organisations receiving funding, has reduced every year since 2017.  The drop between 2018 and 2019 was about 15%.  Between 2017 and 2018, a 34% decline.  As per first half numbers, you could infer, that the identity industry in general is maturing, stabilising and seeing the number of organisations needing funding start to slow.  Approximately 30% of the funding in the second half of 2019, was classified as seed, which may support that claim.

2H2019
  • ~$532 million overall funding
  • Seed funding accounted for 30.3%
  • Median announcement date Sep 26th
  • 33 companies funded

2H2018
  • ~$172 million overall funding
  • Seed funding accounted for 23.1%
  • Median announcement date Aug 29th
  • 39 companies funded

2H2017

  • ~$523 million overall funding
  • Seed funding accounted for 32.8%
  • Median announcement date Oct 3rd
  • 61 companies funded

2H2019 Company Analysis

A coarse grained analysis of the 2019 numbers, shows a pretty balanced geographic spread - between EMEA and North America at least.  Whilst, most funding originates within the US, the companies receiving funding seems quite balanced.  For the first half of 2019, a much larger focus was on organisations based out of North America however.



2H2019 Top 10 Companies By Funding Amounts

The following is a simple top down list, of the companies that received the highest funding and at what stage that funding was received:


1Password ($200m, Series A) - https://pulse2.com/1password-200-million-funding/

AU10TIX ($60m, PE) - https://www.biometricupdate.com/201907/au10tix-receives-60m-investment-to-pay-off-debt-and-fund-growth-initiatives

Truiloo ($52m, Series C) - https://www.geekwire.com/2019/vancouver-startup-truiloo-raises-52m-identity-verification-tech/

2H2019 Identity Management Funding Analysis

Back in July, I wrote an article taking a brief look at venture capitalist funding patterns within the identity and access management space, for the first half of 2019.  I am going to revisit that topic, but for the second half of the year.

Key Facts July to December 2017 / 2018 / 2019

Funding increased 309% year on year for the second half of 2019, compared to the same period in 2018.  Taking a 3 year look, it seems, that perhaps 2018, and not 2019, was the unusual year.


The number of organisations receiving funding, has reduced every year since 2017.  The drop between 2018 and 2019 was about 15%.  Between 2017 and 2018, a 34% decline.  As per first half numbers, you could infer, that the identity industry in general is maturing, stabilising and seeing the number of organisations needing funding start to slow.  Approximately 30% of the funding in the second half of 2019, was classified as seed, which may support that claim.

2H2019
  • ~$532 million overall funding
  • Seed funding accounted for 30.3%
  • Median announcement date Sep 26th
  • 33 companies funded

2H2018
  • ~$172 million overall funding
  • Seed funding accounted for 23.1%
  • Median announcement date Aug 29th
  • 39 companies funded

2H2017

  • ~$523 million overall funding
  • Seed funding accounted for 32.8%
  • Median announcement date Oct 3rd
  • 61 companies funded

2H2019 Company Analysis

A coarse grained analysis of the 2019 numbers, shows a pretty balanced geographic spread - between EMEA and North America at least.  Whilst, most funding originates within the US, the companies receiving funding seems quite balanced.  For the first half of 2019, a much larger focus was on organisations based out of North America however.



2H2019 Top 10 Companies By Funding Amounts

The following is a simple top down list, of the companies that received the highest funding and at what stage that funding was received:


1Password ($200m, Series A) - https://pulse2.com/1password-200-million-funding/

AU10TIX ($60m, PE) - https://www.biometricupdate.com/201907/au10tix-receives-60m-investment-to-pay-off-debt-and-fund-growth-initiatives

Truiloo ($52m, Series C) - https://www.geekwire.com/2019/vancouver-startup-truiloo-raises-52m-identity-verification-tech/

1H2019 Identity Management Funding Analysis

As the first half of 2019 has been and gone, I've taken a quick look at the funding rounds that have taken place so far this year, within the identity and access management space and attempted some coarse grained analysis.  The focus is global and the sector definition is quite broad and based on the categories Crunchbase use.

Key Facts January to June 2017 / 2018 / 2019

Funding increased 261% year on year for the first half of 2019, compared to the same period in 2018.  There were some pretty large, latter stage investments, which looks like that has skewed the number some what.  

The number of organisations actually receiving funding, dropped, as did the % of organisations receiving seed funding.  This is pretty typical as the market matures and stabilises in some sub categories.



1H2019
  • ~$604million overall funding
  • Seed funding accounted for 20%
  • Median announcement date March 27th
  • 35 companies funded

1H2018
  • ~$231million overall funding
  • Seed funding accounted for 45.3%
  • Median announcement date March 30th
  • 53 companies funded

1H2017

  • ~$237million overall funding
  • Seed funding accounted for 32.1%
  • Median announcement date April 7th
  • 56 companies funded


1H2019 Company Analysis

A coarse grained analysis of the 2019 numbers, shows a pretty typical geographic spread - with North America, as ever the major centre, not just for funded companies, but the funding entities too.



The types of companies funded, is also interesting.  The categories are based on what Crunchbase curates, and maps against company descriptions, so there might be some overlap or ambiguity when performing detailed analysis on that.



It's certainly interesting to see a range covering B2C fraud, payments and analytics - typically as the return on investment on such products is very tangible.

The stage of funding, provides a broad and distributed range.  Seed is the clear leader, but the long tail is indicating a maturity of market, with many investors expecting strong returns.


1H2019 Top 10 Companies By Funding Amounts

The following is a simple top down list, of the companies that received the highest funding and at what stage that funding was received:
  1. Dashlane ($110m, Series D) - http://www.dashlane.com/ (https://techcrunch.com/2019/05/30/dashlane-series-d/)
  1. Auth0 ($103m, Series E) - https://auth0.com/ (s://auth0.com/blog/auth0-closes-103m-in-funding-passes-1b-valuation/)
  1. OneLogin ($100m, Series D) - http://onelogin.com/ (https://venturebeat.com/2019/01/10/onelogin-raises-100-million-to-help-enterprises-manage-access-and-identity/)

  2. Onfido ($50m, Series C) - http://www.onfido.com/ (https://venturebeat.com/2019/04/03/onfido-raises-50-million-for-ai-powered-identity-verification/)

  3. Socure ($30m, Series C) - http://www.socure.com/ (https://www.socure.com/about/news/socure-raises-30-million-in-additional-financing-to-identify-the-human-race)
  1. Dashlane ($30m, Debt Financing) - http://www.dashlane.com/
  2. Payfone ($24m, Series G) - http://www.payfone.com/ (https://www.alleywatch.com/2019/05/nyc-startup-funding-top-largest-april-2019-vc/7/)
  1. Evident ($20m, Series B) - https://www.evidentid.com/ (http://www.finsmes.com/2019/05/evident-raises-20m-in-series-b-funding.html)
  1. Bamboocloud ($15m, Series B) - http://www.bamboocloud.cn/ (https://www.volanews.com/portal/article/index/id/1806.html)
  1. Proxy ($13.6m, Series A) - https://proxy.com/ (https://www.globenewswire.com/news-release/2019/03/27/1774258/0/en/Proxy-Raises-13-6M-in-Series-A-Funding-Led-by-Kleiner-Perkins-Emerges-from-Stealth-to-Launch-Its-Universal-Identity-Signal-for-Frictionless-Access-to-Everything-in-the-Physical-Wor.html)

NB - all data and reporting done via Crunchbase.

1H2019 Identity Management Funding Analysis

As the first half of 2019 has been and gone, I've taken a quick look at the funding rounds that have taken place so far this year, within the identity and access management space and attempted some coarse grained analysis.  The focus is global and the sector definition is quite broad and based on the categories Crunchbase use.

Key Facts January to June 2017 / 2018 / 2019

Funding increased 261% year on year for the first half of 2019, compared to the same period in 2018.  There were some pretty large, latter stage investments, which looks like that has skewed the number some what.  

The number of organisations actually receiving funding, dropped, as did the % of organisations receiving seed funding.  This is pretty typical as the market matures and stabilises in some sub categories.



1H2019
  • ~$604million overall funding
  • Seed funding accounted for 20%
  • Median announcement date March 27th
  • 35 companies funded

1H2018
  • ~$231million overall funding
  • Seed funding accounted for 45.3%
  • Median announcement date March 30th
  • 53 companies funded

1H2017

  • ~$237million overall funding
  • Seed funding accounted for 32.1%
  • Median announcement date April 7th
  • 56 companies funded


1H2019 Company Analysis

A coarse grained analysis of the 2019 numbers, shows a pretty typical geographic spread - with North America, as ever the major centre, not just for funded companies, but the funding entities too.



The types of companies funded, is also interesting.  The categories are based on what Crunchbase curates, and maps against company descriptions, so there might be some overlap or ambiguity when performing detailed analysis on that.



It's certainly interesting to see a range covering B2C fraud, payments and analytics - typically as the return on investment on such products is very tangible.

The stage of funding, provides a broad and distributed range.  Seed is the clear leader, but the long tail is indicating a maturity of market, with many investors expecting strong returns.


1H2019 Top 10 Companies By Funding Amounts

The following is a simple top down list, of the companies that received the highest funding and at what stage that funding was received:
  1. Dashlane ($110m, Series D) - http://www.dashlane.com/ (https://techcrunch.com/2019/05/30/dashlane-series-d/)
  1. Auth0 ($103m, Series E) - https://auth0.com/ (s://auth0.com/blog/auth0-closes-103m-in-funding-passes-1b-valuation/)
  1. OneLogin ($100m, Series D) - http://onelogin.com/ (https://venturebeat.com/2019/01/10/onelogin-raises-100-million-to-help-enterprises-manage-access-and-identity/)

  2. Onfido ($50m, Series C) - http://www.onfido.com/ (https://venturebeat.com/2019/04/03/onfido-raises-50-million-for-ai-powered-identity-verification/)

  3. Socure ($30m, Series C) - http://www.socure.com/ (https://www.socure.com/about/news/socure-raises-30-million-in-additional-financing-to-identify-the-human-race)
  1. Dashlane ($30m, Debt Financing) - http://www.dashlane.com/
  2. Payfone ($24m, Series G) - http://www.payfone.com/ (https://www.alleywatch.com/2019/05/nyc-startup-funding-top-largest-april-2019-vc/7/)
  1. Evident ($20m, Series B) - https://www.evidentid.com/ (http://www.finsmes.com/2019/05/evident-raises-20m-in-series-b-funding.html)
  1. Bamboocloud ($15m, Series B) - http://www.bamboocloud.cn/ (https://www.volanews.com/portal/article/index/id/1806.html)
  1. Proxy ($13.6m, Series A) - https://proxy.com/ (https://www.globenewswire.com/news-release/2019/03/27/1774258/0/en/Proxy-Raises-13-6M-in-Series-A-Funding-Led-by-Kleiner-Perkins-Emerges-from-Stealth-to-Launch-Its-Universal-Identity-Signal-for-Frictionless-Access-to-Everything-in-the-Physical-Wor.html)

NB - all data and reporting done via Crunchbase.

12 Steps to Zero Trust Success

A Google search for “zero trust” returns ~ 195Million results.  Pretty sure some are not necessarily related to access management and cyber security, but a few probably are.  Zero Trust was a term coined by analyst group Forrester back in 2010 and has gained popularity since Google started using the concept with their employee management project called BeyondCorp.


It was originally focused on network segmentation but has now come to include other aspects of user focused security management.

Below is a hybrid set of concepts that tries to cover all the current approaches.  Please comment below so we can iterate and add more to this over time.


  1. Assign unique, non-reusable identifiers to all subjects [1], objects [2] and network devices [3]
  2. Authenticate every subject
  3. Authenticate every device
  4. Inspect, verify and validate every object access request
  5. Log every object access request
  6. Authentication should contain 2 of something you have, something you are, something you know
  7. Successful authentication should result in a revocable credential [4]
  8. Credentials should be scoped and follow least privilege [5]
  9. Credentials should be bound to a user, device, transaction tuple [6]
  10. Network communications should be encrypted [7]
  11. Assume all services, API’s and applications are accessible from the Internet [8]
  12. Segment processes and network traffic in logical and operational groups


[1] – Users of systems, including employees, partners, customers and other user-interactive service accounts
[2] – API’s, services, web applications and unique data sources
[3] – User devices (such as laptops, mobiles, tablets, virtual machines), service devices (such as printers, faxes) and network management devices (such as switches, routers)
[4] – Such as a cookie, tokenId or access token which is cryptographically secure.  Revocable shouldn't necessarily be limited to being time bound. Eg revocation/black lists etc.
[5] – Credential exchange may be required where access traverses network or object segmentation.  For example an issued credential for subject 1 to access object 1, may require object 1 to contact object 2 to fulfil the request.  The credential presented to object 2 may differ to that presented to object 1.
[6] – Token binding approach such as signature based access tokens or TLS binding
[7] – Using for example standards based protocols such as TLS 1.3 or similar. Eg Google's ALTS.
[8] – Assume perimeter based networking (either software defined or network defined) is incomplete and trust cannot be placed simply on the origin of a request




The below is a list of companies referencing “zero trust” public documentation:

  • Akamai - https://www.akamai.com/uk/en/solutions/zero-trust-security-model.jsp
  • Palo Alto - https://www.paloaltonetworks.com/cyberpedia/what-is-a-zero-trust-architecture
  • Centrify - https://www.centrify.com/zero-trust-security/
  • Cisco - https://blogs.cisco.com/security/why-has-forresters-zero-trust-cybersecurity-framework-become-such-a-hot-topic
  • Microsoft - https://cloudblogs.microsoft.com/microsoftsecure/2018/06/14/building-zero-trust-networks-with-microsoft-365/
  • ScaleFT - https://www.scaleft.com/zero-trust-security/
  • zscaler - https://www.zscaler.com/blogs/corporate/google-leveraging-zero-trust-security-model-and-so-can-you
  • Okta - https://www.okta.com/resources/whitepaper-zero-trust-with-okta-modern-approach-to-secure-access/
  • ForgeRock  - https://www.forgerock.com/blog/zero-trust-importance-identity-centered-security-program
  • Duo Security - https://duo.com/blog/to-trust-or-zero-trust
  • Google’s Beyond Corp - https://beyondcorp.com/
  • Fortinet - https://www.fortinet.com/demand/gated/Forrester-Market-Overview-NetworkSegmentation-Gateways.html

12 Steps to Zero Trust Success

A Google search for “zero trust” returns ~ 195Million results.  Pretty sure some are not necessarily related to access management and cyber security, but a few probably are.  Zero Trust was a term coined by analyst group Forrester back in 2010 and has gained popularity since Google started using the concept with their employee management project called BeyondCorp.


It was originally focused on network segmentation but has now come to include other aspects of user focused security management.

Below is a hybrid set of concepts that tries to cover all the current approaches.  Please comment below so we can iterate and add more to this over time.


  1. Assign unique, non-reusable identifiers to all subjects [1], objects [2] and network devices [3]
  2. Authenticate every subject
  3. Authenticate every device
  4. Inspect, verify and validate every object access request
  5. Log every object access request
  6. Authentication should contain 2 of something you have, something you are, something you know
  7. Successful authentication should result in a revocable credential [4]
  8. Credentials should be scoped and follow least privilege [5]
  9. Credentials should be bound to a user, device, transaction tuple [6]
  10. Network communications should be encrypted [7]
  11. Assume all services, API’s and applications are accessible from the Internet [8]
  12. Segment processes and network traffic in logical and operational groups


[1] – Users of systems, including employees, partners, customers and other user-interactive service accounts
[2] – API’s, services, web applications and unique data sources
[3] – User devices (such as laptops, mobiles, tablets, virtual machines), service devices (such as printers, faxes) and network management devices (such as switches, routers)
[4] – Such as a cookie, tokenId or access token which is cryptographically secure.  Revocable shouldn't necessarily be limited to being time bound. Eg revocation/black lists etc.
[5] – Credential exchange may be required where access traverses network or object segmentation.  For example an issued credential for subject 1 to access object 1, may require object 1 to contact object 2 to fulfil the request.  The credential presented to object 2 may differ to that presented to object 1.
[6] – Token binding approach such as signature based access tokens or TLS binding
[7] – Using for example standards based protocols such as TLS 1.3 or similar. Eg Google's ALTS.
[8] – Assume perimeter based networking (either software defined or network defined) is incomplete and trust cannot be placed simply on the origin of a request




The below is a list of companies referencing “zero trust” public documentation:

  • Akamai - https://www.akamai.com/uk/en/solutions/zero-trust-security-model.jsp
  • Palo Alto - https://www.paloaltonetworks.com/cyberpedia/what-is-a-zero-trust-architecture
  • Centrify - https://www.centrify.com/zero-trust-security/
  • Cisco - https://blogs.cisco.com/security/why-has-forresters-zero-trust-cybersecurity-framework-become-such-a-hot-topic
  • Microsoft - https://cloudblogs.microsoft.com/microsoftsecure/2018/06/14/building-zero-trust-networks-with-microsoft-365/
  • ScaleFT - https://www.scaleft.com/zero-trust-security/
  • zscaler - https://www.zscaler.com/blogs/corporate/google-leveraging-zero-trust-security-model-and-so-can-you
  • Okta - https://www.okta.com/resources/whitepaper-zero-trust-with-okta-modern-approach-to-secure-access/
  • ForgeRock  - https://www.forgerock.com/blog/zero-trust-importance-identity-centered-security-program
  • Duo Security - https://duo.com/blog/to-trust-or-zero-trust
  • Google’s Beyond Corp - https://beyondcorp.com/
  • Fortinet - https://www.fortinet.com/demand/gated/Forrester-Market-Overview-NetworkSegmentation-Gateways.html

Using the ForgeRock IDM API Explorer

ForgeRock Logo This post is part of a series about how to get live reference documentation for ForgeRock REST APIs.

The ForgeRock IDM web-based console includes an API explorer.

The API explorer lets you try out the CREST HTTP APIs as you are building your service. You access the IDM API explorer from the question mark menu in the console. IDM makes many categories of endpoints available. The following example shows the Health category expanded:

IDM browse explorer.png

You can quickly try out one of the API calls. For example, expand /health/memory, and then click the Try it out and Execute buttons:

IDM try health memory endpoint.png

Notice that the API explorer displays everything but the credentials needed to access the REST API.

You can also get the OpenAPI-format API descriptor for the /health endpoint. You pass the _api query string parameter to the endpoint. The resulting OpenAPI descriptor is a JSON document:

curl -u openidm-admin:openidm-admin -o health-api.json http://localhost:8080/openidm/health?_api

To try out the result, download and install Swagger UI, then move the JSON document into the Swagger UI directory. You can then browse the Swagger UI with health-api.json as the descriptor:

IDM Swagger UI.png

The API descriptor that you load from the server no doubt does not exactly match what you need to publish in your live documentation. Use the Swagger Editor to adapt it to your needs:

IDM Swagger Editor.png

For more information, see API Explorer.

About REST APIs and API Descriptors

ForgeRock Logo This post briefly describes the types of HTTP APIs available through the ForgeRock platform, and which ones come with live reference documentation.

The following categories of HTTP APIs are available in the ForgeRock platform:

ForgeRock Common REST (CREST) APIs

ForgeRock Common REST provides a framework for HTTP APIs. Each of the component products in the platform uses CREST to build APIs that do CRUDPAQ operations in the same ways.

ForgeRock platform component products generate live reference documentation in a standard format (Swagger, which has been standardized as OpenAPI) for CREST APIs. This is done through a mechanism referred to as API descriptors. You can use this documentation to try out the CREST APIs.

Standard HTTP APIs such as OAuth 2.0

Standard HTTP APIs are defined by organizations like the IETF for OAuth 2.0, the Kantara Initiative for UMA, and the OpenID Connect Working Group. These APIs have their own implementations and do not use CREST. They are documented where they are used in the product documentation.

The canonical documentation is the specifications for the standards. At present, the ForgeRock platform components do not generate live documentation for these standard APIs.

Non-RESTful, Challenge-Response HTTP APIs

Some APIs, such as the authentication API used in ForgeRock AM and the user self-service API used in ForgeRock IDM are not fully RESTful. Instead, they use challenge-response mechanisms that have the developer return to the same endpoint with different payloads during a session.

These APIs are documented in the product documentation.

The ForgeRock API reference documentation published with the product docs is, necessarily, abstract. It does not provide you a sandbox to try out the APIs. Unlike a SaaS, with its fixed configuration, the ForgeRock platform components are highly configurable. ForgeRock HTTP APIs depend on how you decide to configure each service.

Live Reference Documentation

It is your software deployment or SaaS, built with the ForgeRock platform, that publishes concrete APIs.

You can capture the OpenAPI-format docs, and edit them to correspond to the APIs you actually want to publish. A browser-based, third-party application, Swagger UI, makes it easy to set up a front end to a sandbox service so your developers can try out your APIs.

Note that you still need to protect the endpoints. In particular, prevent developers from using the endpoints you do not want to publish.

The following posts in this series will look at how to work with the APIs when developing your configuration, and how to get the OpenAPI-format descriptors to publish live API documentation for your developers.

ForgeRock Identity Platform Version 6: Integrating IDM, AM, and DS

For the ForgeRock Identity Platform version 6, integration between our products is easier than ever. In this blog, I’ll show you how to integrate ForgeRock Identity Management (IDM), ForgeRock Access Management (AM), and ForgeRock Directory Services (DS). With integration, you can configure aspects of privacy, consent, trusted devices, and more. This configuration sets up IDM as an OpenID Connect / OAuth 2.0 client of AM, using DS as a common user datastore.

Setting up integration can be a challenge, as it requires you to configure (and read documentation from) three different ForgeRock products. This blog will help you set up that integration. For additional features, refer to the following chapters from IDM documentation: Integrating IDM with the ForgeRock Identity Platform and the Configuring User Self-Service.

While you can find most of the steps in the IDM 6 Samples Guide, this blog collects the information you need to set up integration in one place.

This blog post will guide you through the process. (Here’s the link to the companion blog post for ForgeRock Identity Platform version 5.5.)

Preparing Your System

For the purpose of this blog, I’ve configured all three systems in a single Ubuntu 16.04 VM (8 GB RAM / 40GB HD / 2 CPU).

Install Java 8 on your system. I’ve installed the Ubuntu 16.04-native openjdk-8 packages. In some cases, you may have to include export JAVA_HOME=/usr in your ~/.bashrc or ~/.bash_profile files.

Create separate home directories for each product. For the purpose of this blog, I’m using:

  • /home/idm
  • /home/am
  • /home/ds

Install Tomcat 8 as the web container for AM. For the purpose of this blog, I’ve downloaded Tomcat 8.5.30, and have unpacked it. Activate the executable bit in the bin/ subdirectory:

$ cd apache-tomcat-8.5.30/bin
$ chmod u+x *.sh

As AM requires fully qualified domain names (FQDNs), I’ve set up an /etc/hosts file with FQDNs for all three systems, with the following line:

192.168.0.1 AM.example.com DS.example.com IDM.example.com

(Substitute your IP address as appropriate. You may set up AM, DS, and IDM on different systems.)

If you set up AM and IDM on the same system, make sure they’re configured to connect on different ports. Both products configure default connections on ports 8080 and 8443.

Download AM, IDM, and DS versions 6 from backstage.forgerock.com. For organizational purposes, set them up on their own home directories:

 

Product Download Home Directory
DS DS-6.0.0.zip /home/ds
AM AM-6.0.0.war /home/am
IDM IDM-6.0.0.zip /home/idm

 

Unpack the zip files. For convenience, copy the Example.ldif file from /home/idm/openidm/samples/full-stack/data to the /home/ds directory.

For the purpose of this blog, I’ve downloaded Tomcat 8.5.30 to the /home/am directory.

Configuring ForgeRock Directory Services (DS)

To install DS, navigate to the directory where you unpacked the binary, in this case, /home/ds/opendj. In that directory, you’ll find a setup script. The following command uses that script to start DS as a directory server, with a root DN of “cn=Directory Manager”, with a host name of ds.example.com, port 1389 for LDAP communication, and 4444 for administrative connections:

$ ./setup \
  directory-server \
  --rootUserDN "cn=Directory Manager" \
  --rootUserPassword password \
  --hostname ds.example.com \
  --ldapPort 1389 \
  --adminConnectorPort 4444 \
  --baseDN dc=com \
  --ldifFile /home/ds/Example.ldif \
  --acceptLicense

Earlier in this blog, you copied the Example.ldif file to /home/ds. Substitute if needed. Once the setup script returns you to the command line, DS is ready for integration.

Installing ForgeRock Access Manager (AM)

Use the configured external DS server as a common user store for AM and IDM. For an extended explanation, see the following documentation: Integrating IDM with the ForgeRock Identity Platform. To install AM, use the following steps:

  1. Set up Tomcat for AM. For this blog, I used Tomcat 8.5.30, downloaded from http://tomcat.apache.org/. 
  2. Unzip Tomcat in the /home/am directory.
  3. Make the files in the apache-tomcat-8.5.30/bin directory executable.
  4. Copy the AM-6.0.0.war file from the /home/am directory to apache-tomcat-8.5.30/webapps/openam.war.
  5. Start the Tomcat web container with the startup.sh script in the apache-tomcat-8.5.30/bin directory. This action should unpack the openam.war binary to the
    apache-tomcat-8.5.30/webapps/openam directory.
     
  6. Shut down Tomcat, with the shutdown.sh script in the same directory. Make sure the Tomcat process has stopped.
  7. Open the web.xml file in the following directory: apache-tomcat-8.5.30/webapps/openam/WEB-INF/. For an explanation, see the AM 6 Release Notes. Include the following code blocks in that file to support cross-origin resource sharing:
<filter>
      <filter-name>CORSFilter</filter-name>
      <filter-class>org.apache.catalina.filters.CorsFilter</filter-class>
      <init-param>
           <param-name>cors.allowed.headers</param-name>
           <param-value>Content-Type,X-OpenIDM-OAuth-Login,X-OpenIDM-DataStoreToken,X-Requested-With,Cache-Control,Accept-Language,accept,Origin,Access-Control-Request-Method,Access-Control-Request-Headers,X-OpenAM-Username,X-OpenAM-Password,iPlanetDirectoryPro</param-value>
      </init-param>
      <init-param>
           <param-name>cors.allowed.methods</param-name>
           <param-value>GET,POST,HEAD,OPTIONS,PUT,DELETE</param-value>
      </init-param>
      <init-param>
           <param-name>cors.allowed.origins</param-name>
           <param-value>http://am.example.com:8080,https://idm.example.com:9080</param-value>
      </init-param>
      <init-param>
           <param-name>cors.exposed.headers</param-name>
           <param-value>Access-Control-Allow-Origin,Access-Control-Allow-Credentials,Set-Cookie</param-value>
      </init-param>
      <init-param>
           <param-name>cors.preflight.maxage</param-name>
           <param-value>10</param-value>
      </init-param>
      <init-param>
           <param-name>cors.support.credentials</param-name>
           <param-value>true</param-value>
      </init-param>
 </filter>

 <filter-mapping>
      <filter-name>CORSFilter</filter-name>
      <url-pattern>/json/*</url-pattern>
 </filter-mapping>

Important: Substitute the actual URL and ports for your AM and IDM deployments, where you see http://am.example.com:8080 and http://idm.example.com:9080. (I forgot to make these once and couldn’t figure out the problem for a couple of days.)

Configuring AM

  1. If you’ve configured AM on this system before, delete the /home/am/openam directory.
  2. Restart Tomcat with the startup.sh script in the aforementioned apache-tomcat-8.5.30/bin directory.
  3. Navigate to the URL for your AM deployment. In this case, call it http://am.example.com:8080/openam. You’ll create a “Custom Configuration” for OpenAM, and accept the defaults for most cases.
    • When setting up Configuration Data Store Settings, for consistency, use the same root suffix in the Configuration Data Store, i.e. dc=example,dc=com.
    • When setting up User Data Store settings, make sure the entries match what you used when you installed DS. The following table is based on that installation:

      Option Setting
      Directory Name ds.example.com
      Port 1389
      Root Suffix dc=example,dc=com
      Login ID cn=Directory Manager
      Password password

       

  4. When the installation process is complete, you’ll be prompted with a login screen. Log in as the amadmin administrative user with the password you set up during the configuration process. With the following action, you’ll set up an OpenID Connect/OAuth 2.0 service that you’ll configure shortly for a connection to IDM.
    • Select Top-Level Realm -> Configure OAuth Provider -> Configure OpenID Connect -> Create -> OK. This sets up AM as an OIDC authorization server.
  5. Set up IDM as an OAuth 2.0 Client:
    • Select Applications -> OAuth 2.0. Choose Add Client. In the New OAuth 2.0 Client window that appears, set openidm as a Client ID, set changeme as a Client Secret, along with a Redirection URI of http://idm.example.com:9080/oauthReturn/. The scope is openid, which reflects the use of the OpenID Connect standard.
    • Select Create, go to the Advanced Tab, and scroll down. Activate the Implied Consent option.
    • Press Save Changes.
  6. Go to the OpenID Connect tab, and enter the following information in the Post Logout Redirect URIs text box:
    • http://idm.example.com:9080/
    • http://idm.example.com:9080/admin/
    • Press Save Changes.
  7. Select Services -> OAuth2 Provider -> Advanced OpenID Connect:
    • Scroll down and enter openidm in the “Authorized OIDC SSO Clients” text box.
    • Press Save Changes.
  8. Navigate to the Consent tab:
    • Enable the Allow Clients to Skip Consent option.
    • Press Save Changes.

AM is now ready for integration.

 

Configuring IDM

Now you’re ready to configure IDM, using the following steps:

  1. For the purpose of this blog, use the following project subdirectory: /home/idm/openidm/samples/full-stack.
  2. If you haven’t modified the deployment port for AM, modify the port for IDM. To do so, edit the boot.properties file in the openidm/resolver/ subdirectory, and change the port property appropriate for your deployment (openidm.port.http or openidm.port.https). For this blog, I’ve changed the openidm.port.http line to:
    • openidm.port.http=9080
  3. (NEW) You’ll also need to change the openidm.host. By default, it’s set to localhost. For this blog, set it to:
    • openidm.host=idm.example.com
  4. Start IDM using the full-stack project directory:
    • $ cd openidm
    • $ ./startup.sh -p samples/full-stack
      • (If you’re running IDM in a VM, the following command starts IDM and keeps it going after you log out of the system:
        nohup ./startup.sh -p samples/full-stack/ > logs/console.out 2>&1& )
    • As IDM includes pre-configured options for the ForgeRock Identity Platform in the full-stack subdirectory, IDM documentation on the subject frequently refers to the platform as the “Full Stack”.
  5. In a browser, navigate to http://idm.example.com:9080/admin/.
  6. Log in as an IDM administrator:
    • Username: openidm-admin
    • Password: openidm-admin
  7. Reconcile users from the common DS user store to IDM. Select Configure > Mappings. In the page that appears, find the mapping from System/Ldap/Account to Managed/User, and press Reconcile. That will populate the IDM Managed User store with users from the common DS user store.
  8. Select Configure -> Authentication. Choose the ForgeRock Identity Provider option. In the window that appears, scroll down to the configuration details. Based on the instance of AM configured earlier, you’d change:
    Property Entry
    Well-Known Endpoint http://am.example.com:8080/openam/oauth2/.well-known/openid-configuration
    Client ID Matching entry from Step 5 of Configuring AM (openidm)
    Client Secret Matching entry from Step 5 of Configuring AM (changeme)
  9. When you’ve made appropriate changes, press Submit. (You won’t be able to press submit until you’ve entered a valid Well-Known Endpoint.)
    • You’re prompted with the following message:
      • Your current session may be invalid. Click here to logout and re-authenticate.
  10. When you tap on the ‘Click here’ link, you should be taken to http://am.example.com:8080/openam/<some long extension>. Log in with AM administrative credentials:
    • Username: amadmin
    • Password: <what you configured during the AM installation process>

If you see the IDM Admin UI after logging in, congratulations! You now have a working integration between AM, IDM, and DS.

Note: To ensure a rapid response when the AM session expires, the IDM JWT_SESSION timeout has been reduced to 5 seconds. For more information, see the following section of the IDM ForgeRock Identity Platform sample: Changes to Session and Authentication Modules.

 

Building On The ForgeRock Identity Platform

Once you’ve integrated AM, IDM, and DS, you can:

To visualize how this works, review the following diagram. For more information, see the following section of the IDM ForgeRock Identity Platform sample: Authorization Flow.

 

Troubleshooting

If you run into errors, review the following table:

 

Error message Solution
redirect_uri_mismatch Check for typos in the OAuth 2.0 client Redirection URI.
This application is requesting access to your account. Enable “Implied Consent” in the OAuth 2.0 client.

Enable “Allow Clients to Skip Consent” in the OAuth2 Provider.

Upon logout: The redirection URI provided does not match a pre-registered value. Check for typos in the OAuth 2.0 client Post Logout Redirect URIs.
Unable to login using authentication provider, with a redirect to preventAutoLogin=true. Check for typos in the Authorized OIDC SSO Clients list, in the OAuth2 Provider.

Make sure the Client ID and Client Secret in IDM match those configured for the AM OAuth 2.0 Application Client.

Unknown error: Please contact the administrator.

(In the dev console, you might see: Origin ‘http://idm.example.com:9080’ is therefore not allowed access.’).

Check for typos in the URLs in your web.xml file.
The IDM Self-Service UI does not appear, but you can connect to the IDM Admin UI. Check for typos in the URLs in your web.xml file.

 

If you see other errors, the problem is likely beyond the scope of this blog.

 

ForgeRock welcomes Nabil Maynard

Late welcome to Nabil Maynard who joined the ForgeRock documentation team this past Monday.

Nabil has started working on the identity management documentation. He’s digging into his new full-time job as a writer.

Nabil brings solid technical experience and understanding of how server software works, having been a QA professional for years at places like Dropbox. So much of writing good documentation for ForgeRock software depends on throughly understanding what the software does, how it can be broken, and what you should do to make it work correctly. Nabil’s contributions will surely help you get deeper into ForgeRock’s identity management software.