The Role of Identity Management in the GDPR

Unless you have been living in a darkened room for a long time, you will know the countdown for the EU's General Data Protection Regulation is dramatically coming to a head.  May 2018 is when the regulation really takes hold, and organisations are fast in the act on putting plans, processes and personnel in place, in order to comply.

Whilst many organisations are looking at employing a Data Privacy Officer (DPO), reading through all the legalese and developing data analytics and tagging processes, many need to embrace and understand the requirements with how their consumer identity and access management platform can and should be used in this new regulatory setting.

My intention in this blog, isn't to list every single article and what they mean - there are plenty of other sites that can help with that.  I want to really highlight, some of the more identity related components of the GDPR and what needs to be done.

Personal Data

On the the personal data front, more and more organisations are collecting more data, more frequently than ever before.  Some data is explicit, like when you enter your first name, last name and date of birth when you register for a service for example, through to the more subtle - location, history and preference details amongst others. The GDPR focuses on making sure personal data is processed legally and data is only kept for as long as necessary - with a full end user interface that has the ability to make sure their data is up to date and accurate.

It goes with out saying, that this personal data needs to have the necessary security, confidentiality, integrity and availability constraints applied to it.  This will require the necessary least privileged administrative controls and data persistence security, such as the necessary hashing or encryption.

Lawful Processing

Ah the word law! That must be the legal team. Or the newly appointed DPO. That can't be a security, identity or technology issue.  Partially correct. But the lawful processing, also has a significant requirement surrounding the capture and management of consent.  So what is this explicit consent? The data owner - that's Joe Blogs whose data has been snaffled - needs to be fully aware of the data that has been captured, why it is captured and who has access.

The service provider, also needs to explicitly capture consent - not an implicit "the end user needs to opt out", but more the end user needs to "opt-in" for their data to be used and processed.  This will require a transparent user driven consent system, with sharing and more importantly, timely revocation of access.  Protocols such as User Managed Access may come in useful here.

Individuals Right to be Informed

The lawful processing aspect, flows neatly into the entire area of the end user being informed.  The end user needs to be in a position to make informed decisions, around data sharing, service registration, data revocation and more.  The use of 10 page terms and conditions thrust down the end user's screen at service startup, are over.

Non-tech language is now a must, with clear explanations of why data has been captured and which 3rd parties - if any - have access to the data.  This again flows into the consent model - with the data owner being able to make consent decisions, they need simple to understand information.  So registration flows will now need to be much more progressive - only collecting data when it is needed, with a clear explanation of why the data is needed and what processing will be done with it.  20 attribute registration forms are dead.

Individuals Right to Rectification, Export and Erasure

Certainly some new requirements here - if you are a service provider, can you allow your end users to clearly see what data you have captured about them, and also provide that data in a simple to use end user dashboard where they can make changes and keep it up to date?  What about the ability for the data owner to export that data in a machine readable and standard format such as CSV or JSON?

Right to erasure is also interesting - do you know where your end user data resides?  Which systems, what attributes, what correlations or translations have taken place?  Could you issue a de-provisioning request to either delete, clean or anonymize that data? If not you may need to investigate why and what can be done to remediate that.


Conclusion

The GDPR is big.  It contains over 90 articles, containing lots of legalese and fine grained print.  Don't just assume the legal team or the newly appointed DPO will cover your company's ass.  Full platform data analytics tagging will be needed, along with a modern consumer identity and access management design pattern.  End user dashboards, registration journeys and consent frameworks will need updating.

The interesting aspect, is that privacy is now becoming a competitive differentiator.  The GDPR should not just be seen as an internal compliance exercise.  It could actually be a launch pad for building closer more trusted relationships with your end user community.

ForgeRock Identity Platform 5.0 docs

By now you have probably read the news about the ForgeRock Identity Platform 5.0 release.

This major platform update comes with many documentation changes and improvements:

Hope you have no trouble finding what you need.

This blog post was first published @ marginnotes2.wordpress.com, included here with permission.

ForgeRock Identity Platform 5.0 docs

ForgeRock Logo By now you have probably read the news about the ForgeRock Identity Platform 5.0 release.

This major platform update comes with many documentation changes and improvements:

Hope you have no trouble finding what you need.


We’re hiring

ForgeRock still has open positions in many locations. One of those is for a writer based in our Vancouver, WA office (across the river from Portland, OR).

Be forewarned. This is challenging, hands-on technical writing and reverse engineering work. If you are looking for a gig where you can remain in your comfort zone, skip this one.

On the other hand, if you feel that most things worth doing are tough in the beginning, take a closer look and apply for the job.


We’re hiring

ForgeRock still has open positions in many locations. One of those is for a writer based in our Vancouver, WA office (across the river from Portland, OR).

Be forewarned. This is challenging, hands-on technical writing and reverse engineering work. If you are looking for a gig where you can remain in your comfort zone, skip this one.

On the other hand, if you feel that most things worth doing are tough in the beginning, take a closer look and apply for the job.

This blog post was first published @ marginnotes2.wordpress.com, included here with permission.

Identity Disorder Podcast, Episode 4: The Rodeo of Things

identity-disorder-speakers-ep004

In episode 4, Daniel and Chris are pleased to welcome one of ForgeRock’s founders, Victor Ake. Victor gives his insight into the Identity of Things, talking the differences between constrained and unconstrained devices, how IoT brokers work, securing IoT devices using identity standards, and how microservices fit in to the picture. Other topics include airport hotels, wrestling, and–wait for it–the rodeo.

Episode Links:

ForgeRock IoT Page:
https://www.forgerock.com/solutions/devices-things/

ForgeRock Identity Summit in London and Paris
https://summits.forgerock.com/

All upcoming ForgeRock events:
https://www.forgerock.com/about-us/events/

Identity Disorder Podcast, Episode 2

Identity Disorder, Episode 2: It’s a DevOps World, We Just Live In It

identity-disorder-speakers-ep002

In the second episode of Identity Disorder, join Daniel and me as we chat with ForgeRock’s resident DevOps guru Warren Strange. Topics include why DevOps and elastic environments are a bit like herding cattle, how ForgeRock works in a DevOps world, more new features in the mid-year 2016 ForgeRock Identity Platform release, the Pokémon training center next to Daniel’s house, and if Canada might also consider withdrawing from its neighbors.

Episode Links:

Learn more about ForgeRock DevOps and cloud resources: https://wikis.forgerock.org/confluence/display/DC/ForgeRock+DevOps+and+Cloud+Resources

Videos of the new features in the mid-year 2016 ForgeRock Identity Platform release:
https://vimeo.com/album/4053949

Information on the 2016 Sydney Identity Summit and Sydney Identity Unconference (August 9-10, 2016):
https://summits.forgerock.com/sydney/

All upcoming ForgeRock events:
https://www.forgerock.com/about-us/events/

 

Addendum to ForgeRock Full Stack Configuration – Using ForgeRock OpenIG

This is an extension of an earlier post that demonstrated ForgeRock Full Stack Configuration, comprising OpenDJ, OpenAM and OpenIDM. In here we’ll plug in ForgeRock OpenIG to route traffic to/from OpenAM and OpenIDM. In the video log that follows, you’ll see:

– All urls that hit OpenIG, containing a string ‘openam’ getting redirected to OpenAM URL
– All urls that hit OpenIG, that does not contain the string ‘openam’ getting redirected to:

  1. OpenAM for Authentication if there is no valid User session and then on to OpenIDM UI
  2. OpenIDM UI if there is a valid User session

So here’s the extended illustration

AddendumToFullStackConfiguration

Now on to the video.Enjoy!

This blog post was first published @ www.fedji.com, included here with permission.

Scripted SQL Connector in ForgeRock OpenIDM 4

This blog post was first published @ www.fedji.com, included here with permission.

ForgeRock Identity Management solution includes generic Groovy Connector Toolkit that enables you to run Groovy scripts on any external resource. You can read more about it here. Lifted verbatim from the OpenIDM 4 documentation mentioned above:”To facilitate creating your own scripted connectors with the Groovy Connector Toolkit, OpenIDM provides a scripted connector bundler. ” I followed Instructions in there (as well as in the README file of the ‘sample3’ in OpenIDM installation directory), to build a ScriptedSQL Connector to connect OpenIDM to a MySQL Database and my Video Log is below:

Enjoy!

ForgeRock Full Stack Configuration

This blog post was first published @ www.fedji.com, included here with permission.

If you’re in a hurry to know what each of the ForgeRock Identity Platform Components is meant to do, try the Full Stack Configuration. In just over fifteen minutes, you’ll see:

– Installation of ForgeRock OpenDJ
– Deployment of ForgeRock OpenAM
– Configuration of OpenDJ as an Identity Repository in ForgeRock OpenAM
– Installation of ForgeRock OpenIDM
– Configuring OpenDJ as External Resource in OpenIDM
– Running a reconciliation in OpenIDM from OpenDJ
– Provisioning a User from OpenIDM to OpenDJ
– Using OpenAM as the Authentication Module for OpenIDM

With a much awaited weekend around the corner, I couldn’t really get over the laziness to create a better illustration than the one below to help visualize what’s mentioned above.

ForgeRockFullStack

Please watch it, if you have some time. Enjoy!

Thanks: ForgeRock Product Documentation