ludopoitou.com
Open in
urlscan Pro
192.0.78.25
Public Scan
URL:
https://ludopoitou.com/
Submission: On September 28 via api from CH — Scanned from DE
Submission: On September 28 via api from CH — Scanned from DE
Form analysis 5 forms found in the DOM
GET https://ludopoitou.com/
<form role="search" method="get" class="search-form" action="https://ludopoitou.com/">
<label>
<span class="screen-reader-text">Search for:</span>
<input type="search" class="search-field" placeholder="Search …" value="" name="s">
</label>
<input type="submit" class="search-submit" value="Search">
</form>GET https://ludopoitou.com/
<form role="search" method="get" class="search-form" action="https://ludopoitou.com/">
<label>
<span class="screen-reader-text">Search for:</span>
<input type="search" class="search-field" placeholder="Search …" value="" name="s">
</label>
<input type="submit" class="search-submit" value="Search">
</form><form id="jp-carousel-comment-form">
<label for="jp-carousel-comment-form-comment-field" class="screen-reader-text">Write a Comment...</label>
<textarea name="comment" class="jp-carousel-comment-form-field jp-carousel-comment-form-textarea" id="jp-carousel-comment-form-comment-field" placeholder="Write a Comment..."></textarea>
<div id="jp-carousel-comment-form-submit-and-info-wrapper">
<div id="jp-carousel-comment-form-commenting-as">
<fieldset>
<label for="jp-carousel-comment-form-email-field">Email (Required)</label>
<input type="text" name="email" class="jp-carousel-comment-form-field jp-carousel-comment-form-text-field" id="jp-carousel-comment-form-email-field">
</fieldset>
<fieldset>
<label for="jp-carousel-comment-form-author-field">Name (Required)</label>
<input type="text" name="author" class="jp-carousel-comment-form-field jp-carousel-comment-form-text-field" id="jp-carousel-comment-form-author-field">
</fieldset>
<fieldset>
<label for="jp-carousel-comment-form-url-field">Website</label>
<input type="text" name="url" class="jp-carousel-comment-form-field jp-carousel-comment-form-text-field" id="jp-carousel-comment-form-url-field">
</fieldset>
</div>
<input type="submit" name="submit" class="jp-carousel-comment-form-button" id="jp-carousel-comment-form-button-submit" value="Post Comment">
</div>
</form>POST /
<form action="/" method="post">
<label for="target_email">Send to Email Address</label>
<input type="email" name="target_email" id="target_email" value="">
<label for="source_name">Your Name</label>
<input type="text" name="source_name" id="source_name" value="">
<label for="source_email">Your Email Address</label>
<input type="email" name="source_email" id="source_email" value="">
<input type="text" id="jetpack-source_f_name" name="source_f_name" class="input" value="" size="25" autocomplete="off" title="This field is for validation and should not be changed">
<div class="g-recaptcha" data-sitekey="6LcmyE0UAAAAALID28yVNg7pFCodGaArJzHitez_" data-theme="light" data-type="image" data-tabindex="0" data-lazy="true" data-url="https://www.google.com/recaptcha/api.js?hl=en"></div>
<img style="float: right; display: none" class="loading" src="https://s0.wp.com/wp-content/mu-plugins/post-flair/sharing/images/loading.gif" alt="loading" width="16" height="16">
<input type="submit" value="Send Email" class="sharing_send">
<a rel="nofollow" href="#cancel" class="sharing_cancel" role="button">Cancel</a>
<div class="errors errors-1" style="display: none;"> Post was not sent - check your email addresses! </div>
<div class="errors errors-2" style="display: none;"> Email check failed, please try again </div>
<div class="errors errors-3" style="display: none;"> Sorry, your blog cannot share posts by email. </div>
</form><form>
<li class="actnbr-login-nudge">
<div>Already have a WordPress.com account?
<a href="https://wordpress.com/log-in?redirect_to=https%3A%2F%2Fr-login.wordpress.com%2Fremote-login.php%3Faction%3Dlink%26back%3Dhttps%253A%252F%252Fludopoitou.com%252F2021%252F09%252F16%252Fwe-did-it%252F">Log in now.</a></div>
</li>
</form>Text Content
Skip to content
Primary Menu
* Home
* About
* keybase.txt
Search
Search for:
LUDO SKETCHES
LUDOVIC POITOU BLOG ABOUT IDENTITY, DIRECTORY AND OTHERS…
WE DID IT !
16 September 202116 September 2021LudoLeave 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.
SHARE THIS:
* Twitter
* LinkedIn
* Facebook
* More
*
* Email
* Print
*
* Reddit
* Tumblr
*
* Pinterest
*
LIKE THIS:
Like Loading...
General$FORG, ForgeRock, IPO, NYSE
FORGEROCK DIRECTORY SERVICES 7
12 February 2021LudoLeave 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:
* What has changed?
* Upgrading by adding new servers
* Doing In-place Upgrade
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.
SHARE THIS:
* Twitter
* LinkedIn
* Facebook
* More
*
* Email
* Print
*
* Reddit
* Tumblr
*
* Pinterest
*
LIKE THIS:
Like Loading...
Directory ServicesDirectory Services, Docker, documentation, ForgeRock,
Kubernetes, release, upgrade
DIRECTORY SERVICES CONTAINERIZATION WEBINAR
02 October 2020LudoLeave 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.
SHARE THIS:
* Twitter
* LinkedIn
* Facebook
* More
*
* Email
* Print
*
* Reddit
* Tumblr
*
* Pinterest
*
LIKE THIS:
Like Loading...
Directory Servicescloud, Containers, Directory Services, Docker, Kubernetes,
webinar
SNOWCAMP 2020, C’EST DÉJÀ FINI 😢
27 January 202009 March 2020LudoLeave 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 !
SHARE THIS:
* Twitter
* LinkedIn
* Facebook
* More
*
* Email
* Print
*
* Reddit
* Tumblr
*
* Pinterest
*
LIKE THIS:
Like Loading...
General, InFrench, SoftwareAlps, conference, france, grenoble, snowcamp,
snowcamp.io, SnowCampIO, software, unconference
FORGEROCK SKO IN LAS VEGAS
21 January 202020 January 2020LudoLeave 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.
SHARE THIS:
* Twitter
* LinkedIn
* Facebook
* More
*
* Email
* Print
*
* Reddit
* Tumblr
*
* Pinterest
*
LIKE THIS:
Like Loading...
General, Identityaward, ForgeRock, product-management, sko, team
HAPPY NEW YEAR 2020!
20 January 2020LudoLeave a comment
Wow, time is flying! We’re already past mid-January, and it’s almost getting
late for this! I’m wishing you all a very happy, joyful and prosperous 2020!
Happy New Year!
Bonne Année !
Godt Nytt í
r !
¡ Feliz año nuevo !
あけましておめでとうございます。
…
SHARE THIS:
* Twitter
* LinkedIn
* Facebook
* More
*
* Email
* Print
*
* Reddit
* Tumblr
*
* Pinterest
*
LIKE THIS:
Like Loading...
General
FORGEROCK IDENTITY DAY PARIS (2019)
25 November 201923 November 2019LudoLeave 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.
SHARE THIS:
* Twitter
* LinkedIn
* Facebook
* More
*
* Email
* Print
*
* Reddit
* Tumblr
*
* Pinterest
*
LIKE THIS:
Like Loading...
General, Identity, InFrenchcloud, events, ForgeRock, identity, Identity as a
Service, identityLive, Paris, SaaS
FORGEROCK IDENTITYLIVE LONDON (2019)
14 October 201914 October 2019LudoLeave 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.
SHARE THIS:
* Twitter
* LinkedIn
* Facebook
* More
*
* Email
* Print
*
* Reddit
* Tumblr
*
* Pinterest
*
LIKE THIS:
Like Loading...
GeneralCIAM, Containers, Directory Services, identity, identityLive, Kubernetes,
WomenInIdentity
LDAPCON 2019 UPDATE…
02 August 2019LudoLeave a comment
The Call for Participation has been extended until August 18th.
Please do not wait until last minute to submit your proposals.
SHARE THIS:
* Twitter
* LinkedIn
* Facebook
* More
*
* Email
* Print
*
* Reddit
* Tumblr
*
* Pinterest
*
LIKE THIS:
Like Loading...
Directory Services, General, Identityconference, identity, ldap, ldapcon
LDAPCON 2019
04 July 201902 August 2019LudoLeave 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.
SHARE THIS:
* Twitter
* LinkedIn
* Facebook
* More
*
* Email
* Print
*
* Reddit
* Tumblr
*
* Pinterest
*
LIKE THIS:
Like Loading...
Directory Services, General, Identitycfp, conference, identity, ldap, ldapcon
DIRECTORY SERVICES – DOCKER, KUBERNETES: FRIENDS OR FOES?
18 June 2019Ludo2 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.
SHARE THIS:
* Twitter
* LinkedIn
* Facebook
* More
*
* Email
* Print
*
* Reddit
* Tumblr
*
* Pinterest
*
LIKE THIS:
Like Loading...
Directory Servicesautomation, cloud, Containers, Directory Services,
directory-server, Docker, ForgeRock, Kubernetes, Prometheus
FORGEROCK IDENTITY LIVE BERLIN
12 June 2019Ludo1 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.
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.
SHARE THIS:
* Twitter
* LinkedIn
* Facebook
* More
*
* Email
* Print
*
* Reddit
* Tumblr
*
* Pinterest
*
LIKE THIS:
Like Loading...
GeneralCIAM, conference, Directory Services, ForgeRock, identity, identityLive,
summit
FORGEROCK IDENTITY LIVE NASHVILLE, TN
13 May 2019LudoLeave a comment
Two weeks ago debuted the ForgeRock Identity Live series of events. This year
the USA based event moved to Nashville TN.
This was my first visit to the city of Country Music and honky-tonks. It was fun
listening to the live music everywhere, trying (and buying) boots, visiting the
Country Music Hall of Fame, although we didn’t really have much time for
leisure.
The Identity Live event itself was really good and very well attended. The
engagement of our Customers and Partners was great and we’ve had a myriad of
discussions, feedbacks and questions about our products, our roadmap and our
progress on our move to the Cloud.
The videos of the sessions are already available on ForgeRock website. And you
can also see the photos that I took during the event.
Next is Berlin Identity Live, on June 6-7. Registration is still open! I’m
looking forward to seeing you in Berlin!
SHARE THIS:
* Twitter
* LinkedIn
* Facebook
* More
*
* Email
* Print
*
* Reddit
* Tumblr
*
* Pinterest
*
LIKE THIS:
Like Loading...
GeneralCIAM, conference, ForgeRock, identity, identityLive, Nashville
FORGEROCK DS AND THE LDAP RELAX RULES CONTROL
17 January 201907 January 2019LudoLeave a comment
In ForgeRock Directory Services 6.5, we’ve added the support for the LDAP Relax
Rules Control, both on the server and our clients. One of my colleagues,
involved with the customers’ deployment, asked me why we’ve added the control
and what it should be used for.
The LDAP Relax Rules Control is an LDAP extension that allows a directory user
agent (a client) to request the directory service to temporarily relax
enforcement of various data and service model rules. The internet-draft is
explicit about which rules can be relaxed or not. But typically it can be used
to allow a client to write specific operational attributes that should be
read-only and managed by the server.
Starting with OpenDJ 3.0, we’ve removed the ability to bulk import LDIF data to
a server while preserving the existing data (the “append mode”). First,
performing an import-ldif in append mode was breaking replication. The import
needed to be applied to all replica, while no change was to happen on the new
data. The process was cumbersome, especially when having multiple data-centers.
But also, removing this feature allowed us to have a more generic interface and
implement multiple backend using different underlying key-value stores.
But we have a few customers that have the need to seldom bulk load a large set
of users to their directory service. In DS 6.0, we’ve added an option to speed
bulk operations using ldapmodify or ldapdelete: –numConnections. Instead of
serialising all updates or adds contained in an LDIF file, the tool will run
them in parallel across multiple connections, while also controlling
dependencies of changes. With this options, some of our customers have added
several millions of users to their replicated directory services in minutes. By
controlling the number of connections, one can also balance the need for speed
of bulk loading data against the need to keep bandwidth for the regular client
applications.
Doing bulk updates over LDAP is now fast, but some customers used the import
process to also carry over some attributes that are usually managed by the
directory server and thus read-only, such as the CreateTimeStamp, the
CreatorsName.
And this is specifically what the Relax Rules Control is meant to allow.
So, if you have a need to bulk load large set of data, or synchronise over LDAP
data from another server, and need to preserve some of the operational
attribute, you can use the Relax Rules Control as illustrated below. Note that
the OID for the control is 1.3.6.1.4.1.4203.666.5.12 but ForgeRock DS tools also
recognise the RelaxRules string alias.
$ ldapmodify -p 1389 -D cn=directory\ manager -w secret12
-J RelaxRules:true --numConnections 4 ../50Kusers.ldif
...
ADD operation successful for DN uid=user.10021,ou=People,dc=example,dc=com
ADD operation successful for DN uid=user.10022,ou=People,dc=example,dc=com
ADD operation successful for DN uid=user.10001,ou=People,dc=example,dc=com
ADD operation successful for DN uid=user.10020,ou=People,dc=example,dc=com
ADD operation successful for DN uid=user.10026,ou=People,dc=example,dc=com
ADD operation successful for DN uid=user.10025,ou=People,dc=example,dc=com
ADD operation successful for DN uid=user.10024,ou=People,dc=example,dc=com
ADD operation successful for DN uid=user.10005,ou=People,dc=example,dc=com
ADD operation successful for DN uid=user.10033,ou=People,dc=example,dc=com
ADD operation successful for DN uid=user.10029,ou=People,dc=example,dc=com
...
Note that because the Relax Rules Control allows to override some of the rules
enforced normally by the server, it’s important to control and restrict which
clients or users are allowed to make use of it. In ForgeRock DS, you would use
ACIs (global or not) to define who has permission to use the control. Out of the
box, only Directory Manager can, because it has the bypass access controls
privilege. Check the “Use Control or Extended Operation” section of the
Administration Guide for the details on how to allow a user to use a control.
SHARE THIS:
* Twitter
* LinkedIn
* Facebook
* More
*
* Email
* Print
*
* Reddit
* Tumblr
*
* Pinterest
*
LIKE THIS:
Like Loading...
Directory ServicesDirectory Services, directory-server, extensions, ForgeRock,
howto, ldap
EXPLAINING INDEX-ENTRY-LIMIT IN FORGEROCK DIRECTORY SERVICES / OPENDJ
15 January 201904 January 2019LudoLeave a comment
A few years ago, I’ve explained the various resource limits in OpenDJ, the open
source LDAP and REST directory server. A few months ago, someone read the post
and asked on twitter about the index-entry-limit:
The index-entry-limit is probably the least understood parameter in the OpenDJ
directory server, as was the AllIDThreshold in Sun Directory Server (and its
siblings : Netscape Directory, Red Hat Directory, Oracle DSEE…). So before I
dive in explaining what is this parameter, how it’s used and how it can be
tuned, let me start with answering the question : how does index-entry-limit
relate to other administrative limits ?
Answer: It doesn’t ! The index-entry-limit is an internal limit and does not
really limits the results returned to clients. It just limits the resources
consumed when processing indexes.
A Directory Server is a very specialized data-store based on the LDAP standard,
and its primary goal was to be able to search and return user information such
as email addresses or names and phone numbers, very quickly and for a large
number of different clients. For that, the directory servers were designed to
favor reads over writes, and read optimization was achieved through the use of
indexes.
In LDAP, a search request (which can be used to read an entry or search for one
or more through the whole database) contains a search filter. The filter may be
simple or complex, and composed of one or more attribute value assertions.
A simple filter can be “(sn=Smith)”. Complex filters combine operators and
different attributes : “(&(objectclass=Person)(|(sn=Smith)(cn=*Smith*)))” – find
a person whose surname is smith or whose common name contains smith –
When the ForgeRock Directory Server / OpenDJ receives a search request, it
processes it in 2 phases. In the first phase, it analyzes the search filter, to
identify which attributes are indexed, and then uses these indexes to build a
list of possible candidates to return. If there are no indexed attributes or the
list is too large, the server decides that the list is actually the whole
database. Such search request is tagged as “unindexed” and the server verify if
the authenticated user has the “unindexed-search” privilege before continuing.
In the second phase, it reads all the candidates from the database, and assess
the full filter to decide to return the entry to the client or not (subject to
access controls).
ForgeRock DS / OpenDJ implements attribute indexes as reversed index. Meaning
that for a specific attribute, we keep a pair of each unique value and a list of
the entries that contain that value. Because maintaining a large list of
entries for each value of all indexed attributes may have a big cost, both in
term of memory usage and disk I/O (think that when you add an entry in the
Directory, all of its indexed attributes will need to be updated), we introduced
a limit to the number of entries that an index record can contain: the
index-entry-limit. For example, if the number of entries that contain the
objectClass person exceeds the limit, then we mark the key as “full” and we
consider that the list of candidates is actually the whole set of directory
entries. This saves us from updating and reading a very long record, allocating
lots of data, to end up iterating through almost all entries. You might ask, so
why having an index for objectClass then ? Well, in a directory server that
contains millions of users, there are in fact very few entries that are not
persons. These entries will have their objectClass values indexed, and searching
for those entries will be very efficient thanks for the index.
The index-entry-limit is a limit of the number of entries that are contained in
a single index record, per value of an attribute index. Its default value is
4000 and works for most medium to large scale deployments. So, why is it a
configurable parameter, and when should you change it?
Because ForgeRock DS is used in many different environments with various use
cases, and a great range of number of entries (some of our customers have over
100 millions entries in a directory service), we know that one size doesn’t fit
all. But the default value works for most of the index usages. Also, the
index-entry-limit can be set for each individual index, or for the whole backend
(and this value applies to all indexes that don’t have a specific value). It is
highly recommended that you only try to change the index-entry-limit of specific
indexes, and not the backend default value.
In no case, should you increase the index-entry-limit to a value close to the
total number of entries in the directory. This will undermine performances of
both searches and updates, significantly increase the footprint of the data
stored on disk.
There are few known cases where the index-entry-limit value should be changed
(and equally cases where increasing the value will only consume more resources
for no performance gain). Keep also in mind that when you change the
index-entry-limit, you need to rebuild the indexes for which the limit was
changed. So it’s not something that you want to do too often. And definitely not
something that you need to adjust constantly.
Groups. When the server starts, it issues an internal search to find all group
entries and cache them for better performances. The search is based on the
ObjectClass attribute. If there are more than 4000 groups of one kind (the
search is for GroupOfNames, GroupOfUniqueNames, GroupOfEntries, DynamicGroup and
ds-virtual-static-group), the search will be unindexed and can take a long time
to proceed. In that case, you should increase the index-entry-limit for the
ObjectClass attribute, to a value just above the number of groups.
Members (or uniqueMembers). If you have more than 4000 static groups, and you
know that some users are likely to be member of more than 4000 groups, then you
should also increase the index-entry-limit for the member attribute (or
uniqueMember) to a value just above the maximum number of group a user can be
in, especially if you have enabled the Referential Integrity Plugin (that
removes a user from groups when its entry is deleted).
Another typical use case for increasing the index-entry-limit is when you have
millions of entries, and an attribute doesn’t have a flat distribution of
values. Think about the surname of users. In a wide range of population, there
are probably more “Smith” or “Lee” than “Washington”. Within 10M users, would
there be more than 4000 “Lee”? If it’s possible, and the server receives
searches with filters such as “(sn=Lee)”, then you should consider increasing
the limit for the sn attribute.
Backendstat is the tool you want to use to verify the state of the index and
whether some records have reached the index-entry-limit. For some attributes,
such as ObjectClass, it is normal that the limit is reached. For others, such as
sn, it’s probably something you want to check regularly.
The backendstat tool requires exclusive access to the database, and thus can
only run against a server that is stopped (or a backup).
To list the indexes, use backendstat list-indexes:
$ backendstat list-indexes -b dc=example,dc=com -n userRoot
Index Name Raw DB Name Type Record Count
dn2id /dc=com,dc=example/dn2id DN2ID 10002
id2entry /dc=com,dc=example/id2entry ID2Entry 10002
referral /dc=com,dc=example/referral DN2URI 0
id2childrencount /dc=com,dc=example/id2childrencount ID2ChildrenCount 3
state /dc=com,dc=example/state State 18
uniqueMember.uniqueMemberMatch /dc=com,dc=example/uniqueMember.uniqueMemberMatch MatchingRuleIndex 0
mail.caseIgnoreIA5SubstringsMatch:6 /dc=com,dc=example/mail.caseIgnoreIA5SubstringsMatch:6 MatchingRuleIndex 31232
mail.caseIgnoreIA5Match /dc=com,dc=example/mail.caseIgnoreIA5Match MatchingRuleIndex 10000
aci.presence /dc=com,dc=example/aci.presence MatchingRuleIndex 0
member.distinguishedNameMatch /dc=com,dc=example/member.distinguishedNameMatch MatchingRuleIndex 0
givenName.caseIgnoreMatch /dc=com,dc=example/givenName.caseIgnoreMatch MatchingRuleIndex 8605
givenName.caseIgnoreSubstringsMatch:6 /dc=com,dc=example/givenName.caseIgnoreSubstringsMatch:6 MatchingRuleIndex 19629
telephoneNumber.telephoneNumberSubstringsMatch:6 /dc=com,dc=example/telephoneNumber.telephoneNumberSubstringsMatch:6 MatchingRuleIndex 73235
telephoneNumber.telephoneNumberMatch /dc=com,dc=example/telephoneNumber.telephoneNumberMatch MatchingRuleIndex 10000
ds-sync-hist.changeSequenceNumberOrderingMatch /dc=com,dc=example/ds-sync-hist.changeSequenceNumberOrderingMatch MatchingRuleIndex 0
ds-sync-conflict.distinguishedNameMatch /dc=com,dc=example/ds-sync-conflict.distinguishedNameMatch MatchingRuleIndex 0
entryUUID.uuidMatch /dc=com,dc=example/entryUUID.uuidMatch MatchingRuleIndex 10002
sn.caseIgnoreMatch /dc=com,dc=example/sn.caseIgnoreMatch MatchingRuleIndex 10000
sn.caseIgnoreSubstringsMatch:6 /dc=com,dc=example/sn.caseIgnoreSubstringsMatch:6 MatchingRuleIndex 32217
cn.caseIgnoreMatch /dc=com,dc=example/cn.caseIgnoreMatch MatchingRuleIndex 10000
cn.caseIgnoreSubstringsMatch:6 /dc=com,dc=example/cn.caseIgnoreSubstringsMatch:6 MatchingRuleIndex 86040
objectClass.objectIdentifierMatch /dc=com,dc=example/objectClass.objectIdentifierMatch MatchingRuleIndex 6
uid.caseIgnoreMatch /dc=com,dc=example/uid.caseIgnoreMatch MatchingRuleIndex 10000
Total: 23
To check the status of the indexes and see which keys are full (i.e. exceeded
the index-entry-limit), use backendstat show-index-status. Warning, this may
take a long time.
$ backendstat show-index-status -b dc=example,dc=com -n userRoot
Index Name Raw DB Name Valid Confidential Record Count Over Entry Limit 95% 90% 85%
uniqueMember.uniqueMemberMatch /dc=com,dc=example/uniqueMember.uniqueMemberMatch true false 0 0 0 0 0
mail.caseIgnoreIA5SubstringsMatch:6 /dc=com,dc=example/mail.caseIgnoreIA5SubstringsMatch:6 true false 31232 12 0 0 0
mail.caseIgnoreIA5Match /dc=com,dc=example/mail.caseIgnoreIA5Match true false 10000 0 0 0 0
aci.presence /dc=com,dc=example/aci.presence true false 0 0 0 0 0
member.distinguishedNameMatch /dc=com,dc=example/member.distinguishedNameMatch true false 0 0 0 0 0
givenName.caseIgnoreMatch /dc=com,dc=example/givenName.caseIgnoreMatch true false 8605 0 0 0 0
givenName.caseIgnoreSubstringsMatch:6 /dc=com,dc=example/givenName.caseIgnoreSubstringsMatch:6 true false 19629 0 0 0 0
telephoneNumber.telephoneNumberSubstringsMatch:6 /dc=com,dc=example/telephoneNumber.telephoneNumberSubstringsMatch:6 true false 73235 0 0 0 0
telephoneNumber.telephoneNumberMatch /dc=com,dc=example/telephoneNumber.telephoneNumberMatch true false 10000 0 0 0 0
ds-sync-hist.changeSequenceNumberOrderingMatch /dc=com,dc=example/ds-sync-hist.changeSequenceNumberOrderingMatch true false 0 0 0 0 0
ds-sync-conflict.distinguishedNameMatch /dc=com,dc=example/ds-sync-conflict.distinguishedNameMatch true false 0 0 0 0 0
entryUUID.uuidMatch /dc=com,dc=example/entryUUID.uuidMatch true false 10002 0 0 0 0
sn.caseIgnoreMatch /dc=com,dc=example/sn.caseIgnoreMatch true false 10000 0 0 0 0
sn.caseIgnoreSubstringsMatch:6 /dc=com,dc=example/sn.caseIgnoreSubstringsMatch:6 true false 32217 0 0 0 0
cn.caseIgnoreMatch /dc=com,dc=example/cn.caseIgnoreMatch true false 10000 0 0 0 0
cn.caseIgnoreSubstringsMatch:6 /dc=com,dc=example/cn.caseIgnoreSubstringsMatch:6 true false 86040 0 0 0 0
objectClass.objectIdentifierMatch /dc=com,dc=example/objectClass.objectIdentifierMatch true false 6 4 0 0 0
uid.caseIgnoreMatch /dc=com,dc=example/uid.caseIgnoreMatch true false 10000 0 0 0 0
Total: 18
Index: /dc=com,dc=example/mail.caseIgnoreIA5SubstringsMatch:6
Over index-entry-limit keys: [.com] [@examp] [ample.] [com] [e.com] [exampl] [le.com] [m] [mple.c] [om] [ple.co] [xample]
Index: /dc=com,dc=example/objectClass.objectIdentifierMatch
Over index-entry-limit keys: [inetorgperson] [organizationalperson] [person] [top]
I hope this long article will help you better understand and tune your ForgeRock
Directory Servers for search performances. Please let me know how it goes.
SHARE THIS:
* Twitter
* LinkedIn
* Facebook
* More
*
* Email
* Print
*
* Reddit
* Tumblr
*
* Pinterest
*
LIKE THIS:
Like Loading...
Directory ServicesDirectory Services, directory-server, ForgeRock, index,
performance, troubleshooting, tuning
Previous Articles
CATEGORIES
* Directory Services
* General
* Identity
* Identity Gateway
* InFrench
* Java
* Life
* security
* Software
* Uncategorized
Search for:
SOCIAL
* View ludovic.poitou’s profile on Facebook
* View ludomp’s profile on Twitter
* View ludomp’s profile on Instagram
* View ludovicp’s profile on LinkedIn
* View ludomp’s profile on GitHub
Follow me on
RSS - Posts
RECENT POSTS
* WE DID IT !
* ForgeRock Directory Services 7
* Directory Services Containerization Webinar
* SnowCamp 2020, c’est déjà fini 😢
* ForgeRock SKO in Las Vegas
authentication authorization blog brazil build cloud community conference
developer devoxxfr directory directory-server Directory Services documentation
dsee eic engineering europe events fisl ForgeRock france gateway grenoble i18n
iam identity identity gateway identityLive Identity Relationship Management
IdentitySummit identité index IRM IRMSummit2014 java javaone javaone2012 Json
Kubernetes ldap ldapcon linux localization monitoring office openam opendj
OpenDS openidm openig opensolaris opensource opensso Paris password performance
photography photos products release replication REST search security software
startup summit sun team Tips training troubleshooting tuning video
September 2021 M T W T F S S 12345 6789101112 13141516171819 20212223242526
27282930
« Feb
BLOGROLL
* De l'idée aux mots
* ForgeRock Community Blog Syndication
* My GitHub Account
FOLLOW ME ON TWITTER
My Tweets
META
* Register
* Log in
* Entries feed
* Comments feed
* WordPress.com
LICENSE
This work is licensed under a Creative Commons
Attribution-NonCommercial-ShareAlike 3.0 Unported License.
Blog at WordPress.com.
Ludo Sketches
Blog at WordPress.com.
Loading Comments...
Write a Comment...
Email (Required) Name (Required) Website
%d bloggers like this:
Send to Email Address Your Name Your Email Address
Cancel
Post was not sent - check your email addresses!
Email check failed, please try again
Sorry, your blog cannot share posts by email.
* FollowFollowing
* Ludo Sketches
Already have a WordPress.com account? Log in now.
* * Ludo Sketches
* Customize
* FollowFollowing
* Sign up
* Log in
* Report this content
* Manage subscriptions
* Collapse this bar