ForgeRock Directory Services 7.2 has been released

LudoLeave a comment

ForgeRock Directory Services 7.2 was and will be the last release of ForgeRock products that I’ve managed. It was finished when I left the company and was released to the public a few days after. Before I dive into the changes available in this release, I’d like to thank the amazing team that produced this version, from the whole Engineering team led by Matt Swift, to the Quality engineering led by Carole Forel, the best and only technical writer Mark Craig, and also our sustaining engineer Chris Ridd who contributed some important fixes to existing customers. You all rock and I’ve really appreciated working with you all these years.

So what’s new and exciting in DS 7.2?

First, this version introduces a new type of index: Big Index. This type of index is to be used to optimize search queries that are expecting to return a large number of results among an even much larger number of entries. For example, if you have an application that searches for all users in the USA that live in a specific state. In a population of hundreds of millions users, you may have millions that live in one particular state (let’s say Ohio). With previous versions, searching for all users in Ohio would be unindexed and the search if allowed would scan the whole directory data to identify the ones in Ohio. With 7.2, the state attribute can be indexed as a Big Index, and the same search query would be considered as indexed, only going through the reduced set of users with that have Ohio as the value for the state attribute.

Big Indexes can have a lesser impact on write performances than regular indexes, but they tend to have a higher on disk footprint. As usual, choosing to use a Big Index type is a matter of trade-of between read and write performances, but also disk space occupation which may also have some impact on performances. It is recommended to test and run benchmarks in development or pre-production environments before using them in production.

The second significant new feature in 7.2 is the support of the HAProxy Protocol for LDAP and LDAPS. When ForgeRock Directory Services is deployed behind a software load-balancer such as HAProxy, NGINX or Kubernetes Ingress, it’s not possible for DS to know the IP address of the Client application (the only IP address known is the one of the load-balancer), therefore, it is not possible to enforce specific access controls or limits based on the applications. By supporting the HAProxy Protocol, DS can decode a specific header sent by the load-balancer and retrieve some information about the client application such as IP address but also some TLS related information if the connection between the client and the load-balancer is secured by TLS, and DS can use this information in access controls, logging, limits… You can find more details about DS support of the Proxy Protocol in DS documentation.

In DS 7.2, we have added a new option for securing and hashing passwords: Argon2. When enabled (which is the default), this allows importing users with Argon2 hashed passwords, and letting them authenticating immediately. Argon2 may be selected as well as the default scheme for hashing new passwords, by associating it with a password policy (such as the default password policy). The Argon2 password scheme has several parameters that control the cost of the hash: version, number of iterations, amount of memory to use and parallelism (aka number of threads used). While Argon2 is probably today the best algorithm to secure passwords, it can have a very big impact on the server’s performance, depending on the Argon2 parameters selected. Remember that DS encrypts the entries on disk by default, and therefore the risk of exposing hashed passwords at rest is extremely low (if not null).

Also new is the ability to search for attributes with a DistinguishedName syntax using pattern matching. DS 7.2 introduces a new matching rule named distinguishedNamePatternMatch (defined with the OID 1.3.6.1.4.1.36733.2.1.4.13). It can be used to search for users with a specific manager for example with the following filter “(manager:1.3.6.1.4.1.36733.2.1.4.13:=uid=trigden,**)” or a more human readable form “(manager:distinguishedNamePatternMatch:=uid=trigden,**)”, or to search for users whose manager is part of the Admins organisational unit with the following filter “(manager:1.3.6.1.4.1.36733.2.1.4.13:=*,ou=Admins,dc=example,dc=com)”.

ForgeRock Directory Services 7.2 includes several minor improvements:

As with every release, there has been several performances optimizations and improvements, many minor issues corrected.

You can find the full details of the changes in the Release Notes.

I hope you will enjoy this latest release of ForgeRock Directory Services. If not, don’t reach out to me, I’m no longer in charge. 😀

The end of a chapter

Ludo5 Comments

After almost 12 years, I’ve decided to close the ForgeRock chapter and leave the company.

Now that the company has successfully gone public, and has been set on a trajectory to lead the Identity industry, it was time for me to pause and think about what matters to me in life. So I’ve chosen to leverage the exciting experience I’ve gained with ForgeRock and to start giving back to the startups in my local community.

But what an incredible journey, it has been! I joined the company when it had a dozen employees, I was given the opportunity to found the French subsidiary, to start an engineering center, build an amazing team of developers and deliver some rock solid, highly scalable products. For this opportunity, I will always be thankful to the amazing 5 Founders of ForgeRock.

The ForgeRock Founders: Hermann, Victor, Lasse, Steve, Jonathan.

I have nothing but good memories of all those years, the amazing events organized for all the employees or for our customers. There has been many IdentityLive events (formerly known as Identity Summits), there has been fewer but so energizing Company Meetings, in Portugal, Greece, USA, Italy.

I’ve worked with a team of rock-star product managers, from which I’ve learnt so much:

I’ve hired and built a team of talented and software engineers, some of them I’ve known for 20 years:

I don’t have enough space to write about all the different things we’ve done together, at work, outside work… But yeah, we rocked!

Overall those 12 years have been an incredible and exciting journey, but what made the journey so exceptional is all the persons that have come along. Without you, nothing would have been the same. Thank you ! Farewell but I’m sure we will meet again 😍

ForgeRock Identity Live, Austin TX

LudoLeave a comment

A few weeks ago, ForgeRock organised the first Identity Live event of the season, in Austin TX.

With more than 300 registered guests, an impeccable organisation by our Marketing team, the event was a great success.

The first day was sales oriented, with company presentations, roadmaps, products’ demonstrations but also testimony from existing customers. The second day was focusing on the technical side of the ForgeRock solutions, in an unconference format, where Product Managers, Technical Consultants et Engineers shared with the audience their experience, their knowledge.

It was great to meet again so many colleagues, partners, customers; to have lively conversations about the products, the projects and the overall directions of the Identity technology.

You can find more photos of the event in the dedicated album.

WE DID IT !

LudoLeave a comment

Exactly 11 years ago, I was out of Sun/Oracle and started to work for an emerging startup, with a bunch of former colleagues from Sun (although my official starting date in the French subsidiary is November 1st, which is also my birthdate).

A couple of pictures from my 1st company meeting, in Portugal, end of September 2010.

Fast forward 11 years…

Today is an huge milestone for ForgeRock. We are becoming a public company, with our stock publicly traded under the “FORG” symbol, at the New York Stock Exchange.

I cannot thank enough the founders of ForgeRock for giving me this gigantic opportunity to create the First ForgeRock Engineering Center just outside Grenoble, France, and to drive the destiny of very successful products, especially ForgeRock Directory Services.

ForgeRock Directory Services 7

LudoLeave a comment

In August 2020, we’ve rolled out a new release of the ForgeRock Identity Platform which included updated versions of all of the products, including Directory Services 7.0. I didn’t write a post about the new release, mostly due to our focus to deliver the ForgeRock Identity Cloud and family vacation.

But ForgeRock Directory Services 7.0 is a major release in many ways. It is the first to be released with a sample docker file and full support to run in Kubernetes environments in the Cloud. To achieve that, we’ve made a number of significant changes especially in how security is managed, and how replication is configured and enabled. The rest of the server remains quite the same, delivering consistent performance and reliability. You should read the release notes for all the details.

Since, DS 7 was successfully deployed in production, in VMs or in Docker/Kubernetes, and our customers have praised the simplicity and efficiency of the new version. However, some customers have experienced some difficulties with upgrading their current deployment to the 7.0 release, mostly due to the changes I’ve mentioned above. So we have been improving our Upgrade Guide, with greater details, and my colleague Mark Craig, has posted a series of 3 articles on Upgrading to Directory Services 7:

If you’re planning to upgrade an OpenDJ or a ForgeRock Directory Services to the latest release, I would high recommend to read the Directory Services Upgrade Guide, and then Mark’s posts.

Directory Services Containerization Webinar

LudoLeave a comment

If you’ve missed the webinar I did this week, with Steve Giovannetti, CTO and Co-Founder of Hub City Media, don’t worry: the webinar is available for replay on demand. In the last part of the webinar, we’ve been trying to address many of the questions we’ve received. But if you have some additional questions, I’d be happy to answer them. Just send them to me.

SnowCamp 2020, c’est déjà fini 😢

LudoLeave a comment

La 5ème édition du SnowCamp, la conférence pour les développeurs qui se passe au coeur des Alpes, s’est achevée Samedi dernier. Et ce fut, encore une fois, un superbe événement.

En tant que co-organisateur du SnowCamp, je ne peux qu’être fier de cette conférence qui a accueilli plus de 500 participants et 60 présentateurs. Les retours que nous avons de tous, y compris les sponsors, sont tous positifs et motivants.

C’est difficile de résumer 4 jours en quelques mots, alors je vous laisserai regarder les photos que j’ai faites.

Et j’espère que cela vous donnera envie de participer l’an prochain, en tant que présentateur ou simple participant. Et si jamais vous souhaitez soutenir cette conférence, n’hésitez pas à contacter l’équipe par mail: sponsor@snowcamp.io

A Janvier 2021 !

ForgeRock SKO in Las Vegas

LudoLeave a comment

Last week, ForgeRock ran its annual Sales and Marketing Kick Off on the shores of Lake Las Vegas. It was great week for all of us, getting prepared for 2020. Looking forward to great things again this year!

And I feel really proud and grateful to be part of such an amazing Product Management team.

ForgeRock Identity Day Paris (2019)

LudoLeave a comment

Jeudi 21 Novembre, c’est tenu à Paris le ForgeRock Identity Day, une demi journée d’information sur notre société et nos produits, destinée à nos clients, prospects et partenaires.

Animé par Christophe Badot, VP de la Région France, Benelux, Europe du Sud, cet événement a commencé par une présentation de Alexander Laurie, VP Global Solution Architecture, sur les tendances du marché et la vision de ForgeRock, en Français avec un bel accent Anglais.

Nous avons eu des témoignages de nos clients: CNP Assurance, GRDF et l’Alliance Renault-Nissan-Mitsubishi. Merci à eux d’avoir partagé leurs besoins et la solution apportée par ForgeRock.

Léonard Moustacchis et Stéphane Orluc, Solutions Architects chez ForgeRock, ont fait une démonstration en direct de la force de la Plateforme d’Identité de ForgeRock, à travers une application bancaire web et mobile. Et j’ai eu l’honneur de clore la journée avec une présentation de la roadmap produits, et surtout du ForgeRock Identity Cloud, notre offre SaaS disponible depuis la fin Octobre.

Cette après-midi s’est terminée sur un cocktail qui nous a permis de discuter plus en détail avec les participants. Toutes les photos de l’événement sont visible dans l’album sur mon compte Flickr.

And now the English shorter version:

On Thursday November 21st, we hosted ForgeRock Identity Day in Paris, a half day event for our customers, prospect customers and partners. We presented our vision of the identity landscape, our products and the roadmap. And three of our French customers : CNP Assurances, GRDF, Renault-Nissan-Mitsubishi Alliance, presented how ForgeRock has helped them with their digital transformation and identity needs. My colleagues from the Solutions Architect team ran a live demo of our web and mobile sample banking applications, to illustrate the power of the ForgeRock Identity Platform. And I closed the day with a presentation of the product roadmap and especially of ForgeRock Identity Cloud, our solution as a service. As usual, all my photos are visible in this public Flickr album.

ForgeRock IdentityLive London (2019)

LudoLeave a comment

Last week, I was in London to attend the last ForgeRock IdentityLive summit of 2019. Once again, it was a great event, very well attended by over 250 customers and prospects, in locations close to London Bridge. The first day was packed with presentations from ForgeRock (keynote, roadmap, demos by the Product Management team…) and from 5 different customers: E-Trade, Hargreaves Lansdown, SwissCom, NHS Digital and BMW. I really enjoyed these customers’ testimony and I want to address special kudos to Anthony Wilson, Product Manager for Identity at NHS Digital, for running a live (and successful) demo of an iPad application specifically built for paramedics to allow them to access patients medical records, in a highly trusted yet password-less manner.

The second day is the usual unSummit, with more technical discussions and hands-on workshops. I ran a session about my favorite subject: Directory Services, and everyone else favorite subject: Containers and Kubernetes. I explained all the work we’re doing to automate the deployment of replicated DS instances and ran a live demonstration of deploying a 3 way replicated service on MiniKube on my laptop, in a couple of minutes; and also how to scale it up to 4 instances in just a click. Kudos to the Directory Services engineering team for reaching that milestone on the way to the 7.0 release of the ForgeRock Identity Platform.

During the event, we also showed our support for Women In Identity, a program I’m particularly fond of, as a father of 3 girls (although probably none of them will work in Identity or even IT).

Finally, here’s the obligatory link to my photo album of IdentityLive London.

LDAPCon 2019

LudoLeave a comment

The 7th International LDAP Conference has been announced and will take place in Sofia, Bulgaria on November 4-6. The first day will be reserved for workshops, the main conference taking place on the 5th and 6th.

 Some rights reserved by deensel

LDAPCon brings together vendors, developers, active LDAP practitioners, system administrators to share their experiences about service operations, interoperability, application development and discuss LDAP at large, in a friendly and passionated atmosphere.

A call for participation has been opened and will remain open until August 1st 18th.

Update on CfP closure, now August 18th.

Directory Services – Docker, Kubernetes: Friends or Foes?

Ludo2 Comments

Two weeks ago, at the ForgeRock Identity Live conference, I did a talk about ForgeRock Directory Services (DS) in the Docker/Kubernetes (K8S) world, trying to answer the question whether DS and Docker/K8S were friends or foes.

Before I dive into the question, let me say that it’s obvious that our whole industry is moving to the Cloud, and that Docker/Kubernetes are becoming the standard way to deploy software in the Cloud, in any Cloud. Therefore whether DS and K8S are ultimately friends or foes is not the right question. I believe it is unavoidable and that in the near future we will deploy and fully support Directory Services in K8S. But is it a good idea to do it today? Let’s examine why we are questioning this today, what are the benefits of using Kubernetes to deploy software, what are the constraints of deploying the current version of Directory Services (6.5) in Kubernetes, and what ForgeRock is working on to improve DS in K8S. Finally I will highlight why Directory Services is a good solution to persist data, whether it’s on premise or in the Cloud. 

Why the discussion about DS and K8S?

The main reason we are having this discussion is due to the nature of Directory Services. DS is not the usual stateless web application. Directory Services is both a stateful application and a distributed one. These are two main aspects that require special care when trying to deploy in containers. First Directory Services is a stateful application because it is the place where one can store the state for all these stateless web-applications. In our platform, we use DS to store ForgeRock Access Management data, whether it’s runtime configuration data, tokens and user identities. Second Directory Services is a distributed application because instances need to talk with each other so that the data is replicated and consistent. Because databases and distributed applications require stronger orchestration and coordination between elements of the system, they are implemented as Stateful Sets in the Kubernetes world, and make use of Persistent Volumes (PV). Therefore our Cloud Deployment Model of ForgeRock Directory Services is also implemented this way.

It’s worth noting that Persistent Volume is a Kubernetes API and there are several types of volumes and many different providers implementations. Some of the PV types are very recent and still beta versions. So, when using Kubernetes for applications that persist data, you should have a good understanding of the characteristics and the performance of the Persistent Volumes choices that are available in your environment.

Benefits of Containers and Kubernetes

Developers are making a great use of containers because it simplifies focus on what they have to build and test. Instead of spending hours figuring how to install and configure a database, and build a monitoring platform to validate their work, they can pull one or more docker images that will automate this task.

When going into production, the automation is a key aspect. Kubernetes and its family of tools, allow administrators to describe their target architectures, automate deployment, monitoring and incident response. Typically in a Kubernetes cluster, if the administrator requires at least 3 instances of an application, Kubernetes will react to the disappearance of an instance and will restart a new one immediately. Another key benefit of Kubernetes is auto-scalability. The Kubernetes deployment can react to monitoring alerts or external signals to add or remove instances of an application in order to support a greater or smaller workload. This optimises the cost of running the solution, balancing the capacity to absorb peak loads with the cost of running at normal or low usage levels.

Directory Services 6.5 constraints in K8S

But auto-scaling is not something that is suitable to all applications, and typically Directory Services, like most of the databases, does not scale automatically by adding more running instances. Because databases have state and data, and expect exclusive access to the files, adding a new replica is a costly operation. The data needs to be duplicated in order to let another instance using it. Also, adding a Directory Services instance only helps to scale read operations. A write operation on any server will need to be replicated to all other servers. So all servers will have the same write throughput and the same amount of disk I/Os. In the world of databases, the only way to scale write operations is to distribute (shard) the data to multiple servers. Such capability is not yet available in Directory Services, but it’s planned for future releases. (Note that Directory Proxy Services 6.5 already has support for sharding, but with some constraints. And the proxy is not yet part of the Cloud Deployment Model).

Another constraint of Directory Services 6.5 is how replication works. The DS replication feature was designed years ago when customers would deploy servers and would not touch them unless they were broken. Servers had stable hostnames or IP addresses and would know all of their peers. In the container world, the address of an instance is only known after the instance is started. And sometimes you want to start several instances at the same time. The current ForgeRock Cloud Deployment Model and the Directory Services docker images that we propose, work around the design limitation of replication management, by pre-configuring replication for a fixed (and small) maximum number of replicas. It’s not possible to dynamically add another replica after that. Also, the “dsreplication” utility cannot be used in Kubernetes. Luckily, monitoring replication and more importantly its latency is possible with Prometheus which is the default monitoring technology in Kubernetes.

Coming Improvements in Directory Services

For the past year, we’ve been working hard on redesigning how we manage and bootstrap replication between Directory Services instances. Our main challenge with that work has been to do it in a way that allows us to continue to replicate with previous versions. Interoperability and compatibility of replication between different versions of Directory Services has been and will remain a key value of the product, allowing customers to roll out new versions with zero downtime of the service. We’re moving towards using full CA-based certificates and mutual TLS authentication for establishing trust between replicas. Configuring a new replica will no longer require updating all servers in the topology, and replicas that are uninstalled or stopped for some time will be automatically removed from the topology (and so will be their associated change logs and meta-data). When starting a new replica, it will only need to know of one other running replica (or be told that it is the first one). These changes will make automating the deployment of new replica much simpler and remove the limit to the number of replicas. We are also improving the way we are doing backup and restore of a database backend or the whole server, allowing to directly use cloud buckets such as S3 or GCS. All of these things are planned for the next major release due in the first half of 2020. Most of these features will be used by our own ForgeRock Identity Platform as a Service offering that will go in stages of Early Access and Beta later this year.

Once we have the ability to fully automate the deployment and the upgrade of a cluster of Directory Services instances, in one or more data-centres, we will start working on horizontal scalability for Directory Services, and provide a way to scale the number of servers as the data stored grows, allowing a consistent level of write throughout. All of this fully automated to be deployed in the Cloud using Kubernetes.

Benefits of using Directory Services as a data store

Often people ask me why they should use ForgeRock Directory Services rather than a real database. First of all, Directory Services is a database. It’s a specialised database, built on a standard data model and a standard access protocol: Lightweight Directory Access Protocol aka LDAP. Several people in the past have pointed out that LDAP might have even been the first successful NoSQL database! 🙂  Furthermore, Directory Services also exposes all of the data through a REST/JSON API, yet still providing the same security and fine grained access controls mechanisms as through LDAP. But the main value of Directory Services is that you can achieve very high availability of the data (in the 5 9’s), using standard systems (whether they are bare metal systems or virtual hosts or containers), even with world wide geographic distribution. We have many customers that have deployed a single directory services distributed in 3 to 6 data centers around the globe. The LDAP data model has a flexible schema that can be extended, customised without having to rebuild the database nor even restart the servers. The data can even be exposed through versioned APIs using our REST API. Finally, the combination of flexible and extensive schema with fine-grained access controls, allow multiple applications to access the data, but with great control of which application can read or write which data. This results in a single identity and credentials for a user, but multiple sets of attributes, that can be shared by applications or restricted to a single one: a single central view of the user that is then easier and more cost effective to manage.

Conclusion

Back to the track of Kubernetes, and because of the constraints of the current Directory Services Cloud Deployment Model with version 6.5, we would recommend that you try to keep your Directory Services deployed in VMs or on bare metal. But with the next release which underpins the ForgeRock Cloud offering, we will fully support deploying Directory Services on Docker/Kubernetes. We will continue our investment in the product to be able to support Auto-Scaling (using data sharding) in subsequent releases. Building these solutions is not extremely difficult, but we need time to prove that it’s 100% reliable in all conditions, because in the end, the most wanted and appreciated feature of ForgeRock Directory Services is its reliability.

ForgeRock Identity Live Berlin

Ludo1 Comment

Last week, the IdentityLive tour stopped in Berlin for the first European event of 2019 (the second one will be in London on October 8th-9th).

It was a good opportunity to meet and discuss with our European customers (or the European teams of our global customers). For me, the main topic of discussion was Kubernetes and running Directory Services in Docker/K8S. It was also something that I’ve discussed a little bit during the Nashville Identity Live, but not as much as I did in Berlin. I also did a talk on that subject at the Identity Live Cloud Workshop (the second day of the event is focusing on the technical aspects of our products and solutions). I’ve started to write another article to detail my talk. I hope to publish it here in the next few days. Meanwhile, you can find all the photos from Identity Live Berlin on my Flickr page as usual.

ForgeRock IdentityLive Berlin 2019

Note that Identity Live Berlin took place at the “Classic Remise” which is a showroom for old and sports cars. An unusual place for a conference, but a good opportunity to admire some pretty old cars and try to take a different kind of photos.

Cars from Classic Remise Berlin