Après Londres, Identity Live arrive à Paris

Le ForgeRock Identity Live de Londres vient tout juste de se terminer, et déjà je suis impatient du prochain, le dernier pour l’année 2018: Identity Live Paris.

parissummitsocial_01

Venez nous retrouver, rencontrer des clients, des leaders d’opinions, des experts technique et autres professionnels de l’identité numérique. Pour la première fois, cette année, vous aurez aussi la possibilité, le 14 Novembre, de rencontrer et de discuter avec les experts techniques des produits, les développeurs, sous un format “UnConference” : agenda mouvant, discussions interactives sur les nouvelles fonctionnalités, sur les bonnes pratiques avec les containeurs Docker et Kubernetes…

Il est encore temps de s’inscrire !

En espérant vous retrouver à Paris les 13 et 14 Novembre…

[Mise à jour post-évenement]:
Vous pouvez trouver les quelques photos que j’ai faites ici.

Untitled

Identity Live London is over, Paris is next…

It’s been a couple of intense days in London with over 200 attendees at the London stop of the ForgeRock Identity Live world tour.

Untitled

In London, we’ve had 3 important customers that explained how they are innovating with the help of digital identities, each of them providing online services to over 30 millions users: The BBC, Maerks and Pearson. And we’ve had 3 major UK banks that joined a panel to discuss OpenBanking and APIs in the banking industry. I have particularly enjoyed the well mastered presentations by Bianca Lopes about the data that we leave online and that ties back to our identity, and by Spencer Kelly, technology presenter of the BBC show “Click”.

UntitledToday, we had our “unConference” day, where the engineering team is joining the product management one and discuss with our customers and partners on how to leverage the newest features of the ForgeRock Identity Platform, whether already released or soon to be.

My photos of the Identity Live London are now publicly visible here: https://www.flickr.com/photos/ludovicpoitou/albums/72157701508676261

And now, on to the next and last stop for 2018: Paris, November 13 and 14. Register and join us!

parissummitsocial_01

[Post Event Update]

You can find the few photos that I’ve taken on the Flickr album.

Untitled

Renewable Security: Steps to Save The Cyber Security Planet

Actually, this has nothing to-do with being green.  Although, that is a passion of mine.  This is more to-do with a paradigm that is becoming more popular in security architectures: that of being able to re-spin particular services to a known “safe” state after breach, or even as a preventative measure before a breach or vulnerability has been exploited.

Triple R's of Security


This falls into what is known as the “3 R’s of Security”.  A quick Google on that topic will result in a fair few decent explanations of what that can mean.  The TL;DR is basically, rotate (credentials), repair (vulnerabilities) and repave (services and servers to a known good state).  This approach is gaining popularity mainly due devops deployment models.  Or “secdevops”.  Or is it “devsecops”?  Containerization and highly automated “code to prod” pipelines make it a lot easier to get stuff into production, iterate and go again.  So how does security play into this?

Left-Shifting 


Well I want to back track a little, and tackle the age old issue of why security is generally applied as a post live issue.  Security practitioners, often evangelise on the “left shifting” of security.  Getting security higher up the production line, earlier in the software design life cycle and less as an audit/afterthought/pen testing exercise.  Why isn’t this really happening?  Well anecdotally, just look at the audit, pen testing and testing contractor rates.  They’re high and growing.  Sure, lots of dev teams and organisations are incorporating security architecture practices earlier in the dev cycle, but many find this too slow, expensive or inhibitive.  Many simply ship insecure software and assume external auditors will find the issues.

This I would say has resulted in variations of R3.  Dev as normal and simply flatten and rebuild in production in order to either prevent vulnerabilities being exploited, or recover from them faster.  Is this the approach many organisations are applying to newer architectures such as micro-services, server-less and IoT?

IoT, Microservices and Server-less


There are not many mature design patterns or vendors for things like micro-services security or even IoT security.  Yes, there are some interesting ideas, but the likes of Forrester, Gartner and other industry analysts, don’t to my knowledge, describe security for these areas as a known market size, or a level of repeatable maturity.  So what are the options?  These architectures ship with out security? Well, being a security guy, I would hope not.  So, what is the next best approach?  Maybe the triple R model is the next best thing.  Assume you’re going to breached – which CISO’s should be doing anyway – and focus on a remediation plan.

The triple R approach does assume a few things though.  The main one, is that you have a known-safe place.  Whether that is focused on images, virtual machines or new credentials, there needs to be a position which you can rollback or forward to, that is believed to be more secure than the version before.  That safe place, also needs to evolve.  There is no point in that safe place being unable to deliver the services needed to keep end users happy.

Options, Options, Options...


The main benefit of the triple R approach, is you have options – either as a response to a breach or vulnerability exposure, or as a preventative shortcut. It can bring other more pragmatic issues however.  If we’re referring to things like IoT security – how can devices, in the field and potentially aware from Internet connectivity – be hooked, rebuilt and re-keyed?  Can this be done in a hot-swappable model too, without interruptions to service?  If you need to rebuild a smart meter, you can’t possibly interrupt electricity supply to the property whilst that completes.

So the R3 model is certainly a powerful tool in the security architecture kit bag.  Is is suitable for all scenarios?  Probably not.  Is it a good “get out of jail” card in environments with highly optimized devops-esque process?  Absolutely.

Renewable Security: Steps to Save The Cyber Security Planet

Actually, this has nothing to-do with being green.  Although, that is a passion of mine.  This is more to-do with a paradigm that is becoming more popular in security architectures: that of being able to re-spin particular services to a known “safe” state after breach, or even as a preventative measure before a breach or vulnerability has been exploited.

Triple R's of Security


This falls into what is known as the “3 R’s of Security”.  A quick Google on that topic will result in a fair few decent explanations of what that can mean.  The TL;DR is basically, rotate (credentials), repair (vulnerabilities) and repave (services and servers to a known good state).  This approach is gaining popularity mainly due devops deployment models.  Or “secdevops”.  Or is it “devsecops”?  Containerization and highly automated “code to prod” pipelines make it a lot easier to get stuff into production, iterate and go again.  So how does security play into this?

Left-Shifting 


Well I want to back track a little, and tackle the age old issue of why security is generally applied as a post live issue.  Security practitioners, often evangelise on the “left shifting” of security.  Getting security higher up the production line, earlier in the software design life cycle and less as an audit/afterthought/pen testing exercise.  Why isn’t this really happening?  Well anecdotally, just look at the audit, pen testing and testing contractor rates.  They’re high and growing.  Sure, lots of dev teams and organisations are incorporating security architecture practices earlier in the dev cycle, but many find this too slow, expensive or inhibitive.  Many simply ship insecure software and assume external auditors will find the issues.

This I would say has resulted in variations of R3.  Dev as normal and simply flatten and rebuild in production in order to either prevent vulnerabilities being exploited, or recover from them faster.  Is this the approach many organisations are applying to newer architectures such as micro-services, server-less and IoT?

IoT, Microservices and Server-less


There are not many mature design patterns or vendors for things like micro-services security or even IoT security.  Yes, there are some interesting ideas, but the likes of Forrester, Gartner and other industry analysts, don’t to my knowledge, describe security for these areas as a known market size, or a level of repeatable maturity.  So what are the options?  These architectures ship with out security? Well, being a security guy, I would hope not.  So, what is the next best approach?  Maybe the triple R model is the next best thing.  Assume you’re going to breached – which CISO’s should be doing anyway – and focus on a remediation plan.

The triple R approach does assume a few things though.  The main one, is that you have a known-safe place.  Whether that is focused on images, virtual machines or new credentials, there needs to be a position which you can rollback or forward to, that is believed to be more secure than the version before.  That safe place, also needs to evolve.  There is no point in that safe place being unable to deliver the services needed to keep end users happy.

Options, Options, Options...


The main benefit of the triple R approach, is you have options – either as a response to a breach or vulnerability exposure, or as a preventative shortcut. It can bring other more pragmatic issues however.  If we’re referring to things like IoT security – how can devices, in the field and potentially aware from Internet connectivity – be hooked, rebuilt and re-keyed?  Can this be done in a hot-swappable model too, without interruptions to service?  If you need to rebuild a smart meter, you can’t possibly interrupt electricity supply to the property whilst that completes.

So the R3 model is certainly a powerful tool in the security architecture kit bag.  Is is suitable for all scenarios?  Probably not.  Is it a good “get out of jail” card in environments with highly optimized devops-esque process?  Absolutely.

The OpenID Connect Neighborhood

Understand OpenID Connect by analogy and learn how it relates to OAuth2.

In my last article, I described the benefits of living in the OAuth2 apartment building. Something I didn’t mention is that the neighborhood my building is in is really unique, too. There are several other buildings like mine (OAuth2-enabled) in the area, which has turned out to be very convenient for the local businesses and for the residents. I’ll give you an example of how this arrangement has benefited us all.

I was walking through the lobby recently and saw another advertisement on the community bulletin board, this time for “Ripley’s Gym”. They were offering a special discount for all new members, exclusively for people who live in one of the OAuth2-style apartments.

I knew that it was long past time to start exercising regularly, so I decided to call them up. This gym was very eager to sign up new members – competition is quite stiff for these sorts of businesses. To make it as easy as possible to get me started, they were willing to send Ripley himself over to meet me in the building lobby only a few minutes after I called.

Ripley had previously made a partnership agreement with the management of each of the neighborhood buildings. This partnership meant that there was a smooth process available for him to get the necessary details about each tenant when they signed up. It also meant that he knew that the people signing up were actually tenants in the building.

When he showed up to meet me, I saw the process first hand. First, I met Amy (remember her from my other article?) at the front-desk, along with Ripley. I showed Amy my driver’s license, and Ripley showed her his business card. Amy then had me sign a quick release document which stated that I was okay with Ripley having some of my personal information: name, age, gender, mailing address, phone number, and email address. Given that this meant I didn’t have to fill out a tedious membership form, I was happy to sign Amy’s release document.

Amy then printed out a small ticket for Ripley which had all of that information on it. One really cool thing about this ticket is that Ripley was able to instantly scan it and use the information within to register me at the gym. This was possible because the information on the ticket was standardized – every single OAuth2-style apartment building in the neighborhood is able to print off these same types of tickets with the same standard details about the tenant. Each ticket is also watermarked with the building address that it came from, which means that only legitimate tickets will be recognized.

Now that I was registered with Ripley’s Gym, there was another neat option available to me as a tenant from one of these buildings. Every time I wanted to go to the gym, I just needed to grab a ticket from the apartment front-desk on my way out the door (they can print these very quickly). I can use this ticket when I get to the gym as a means of identification, and also as a simple way to keep my customer information current within the gym’s files. You see, if my phone number or email address (or anything else about me) changes over the course of my time as a gym customer, I won’t have to remember to keep them updated – these details are stored on the tickets, so every time I visit the gym they have the latest information.

Nothing about this ticket-issuing process is unique to Ripley’s Gym. Any of the local businesses that are willing to follow this process are welcome to do so, and many of them do. Likewise, when a new building is opened the details about how businesses can start serving its tenants are published in the lobby. These details always follow a well-known template, making it very easy for businesses to serve those tenants.

Working with the local businesses like this has become a way of life for the people in our neighborhood, which has made things easier for everyone. We no longer have to deal with repeatedly filling out customer sign-up forms or updating our personal information, and we no longer need to worry about having to carry keys for each of the members-only services we want to use. Instead we just get a quick ticket from the front desk and we are on our way. Honestly, I tend to avoid businesses that don’t follow this process – it’s just not worth the hassle.

You might notice there is some similarity between the experience I described with “Clint’s Dog-Walking Service” and “Ripley’s Gym”. In both cases, I met the owner at the front-desk with Amy, and in both cases I signed a form granting my consent for Amy to offer something to the business owner on my behalf. In Clint’s case, he was getting a key card to be able to open some of my apartment doors; in Ripley’s case, he was getting a ticket that had some of my personal information on it. The difference between key cards and tickets may sound obvious, but it is worth highlighting some of those differences:

  • Information stored within the key card is hidden from the person receiving it; information stored within the ticket is intended to be read by the person receiving it.
  • The key card can be used to open apartment doors; the ticket does not imply any such authorization.
  • The ticket can be used as a standard and secure means of identification; using a key card as a means of proving your identity would be awkward, imprecise and would vary from building to building.

Despite these different uses, it is quite convenient to have a similar process for both. Amy does a great job of facilitating these interactions; she has all of the tenant information, consent forms, ticket printers and key card machines that are necessary to make everything work quickly and easily. Also, in more and more cases businesses want a ticket and a key card at the same time, since this makes it easier for them to keep track of whose key card is whose. Given that, having Amy handle it all only makes sense.

No surprises here: this isn’t really my neighborhood. It’s OpenID Connect. This analogy explains why OpenID Connect was created and how it relates to OAuth2.

As you can tell from the analogy, OpenID Connect (OIDC) is designed to solve a very different problem than OAuth2. OIDC is designed to help identify people consistently, regardless of the “identity provider” which is being used.  OAuth2 is designed to request limited access to people’s resources, and is highly specific to the resources in question. As I mentioned above, though these uses are different they are often complementary.

In my analogy, Ripley’s Gym is known as a “relying party.” A relying party is any entity that uses (or “relies” upon) an external identity provider in order to establish the identity of its users.

Each of the “OAuth2-style apartment buildings” is an example of an identity provider. The main thing that a relying party needs from an identity provider is an “id token“. These are the “tickets” that I described – they are in a standard format (known as a JWT) that contain various details about the user and they are cryptographically signed by the provider (conceptually, this is similar to a watermark). These id tokens are suitable for registering users (as Ripley did when I first signed up for the gym) as well as logging users in (as I described using them to get inside the gym).

Given that one of the main points of OIDC is interoperability between providers, all OIDC identity providers are required to publish a “discovery document” which tells the relying parties exactly how to work with it. This is that “well-known” template I mentioned that the neighborhood apartment buildings had to have available. The discovery document includes details like where to go in order to authorize users, where to get tokens, where to get information about users, etc….

You can use ForgeRock Access Management (AM) to implement the role of an OIDC Identity Provider. There are many libraries certified by the OpenID Foundation which can help you build a relying party. If your relying party software can’t be made to work as an RP directly, you should also consider using the filter provided by ForgeRock Identity Gateway to build this feature.

By building your software services using this pattern, you will foster a convenient and secure environment for your users and your business partners. Go forth and be part of the OpenID Connect neighborhood!

ForgeRock IdentityLive APAC

Last month, ForgeRock hosted two IdentityLive events in the Asia-Pacific region.

One in Sydney on August 7 and 8

Sydney Australia

And the second one in Singapore the week after.

Singapore

This was my first participation to the events in this region (somehow I managed to convince my family to move our vacation earlier so I could attend), and it was great meeting in person with many customers and prospects I’ve interacted with over the phone, as well as meeting the ForgeRock colleagues I hadn’t seen for a while. As usual, the conversations around our products and the customers solutions were very rich and open, and I came back with great inputs and confirmations for our roadmaps.

You can find my photos of the events in the following Flickr albums:

The next IdentityLive events will take place in London on October 30-31, and Paris on November 13-14. I hope to see you there!

The OAuth2 Apartment Building

Understand core OAuth2 concepts by analogy and learn how the various ForgeRock Identity Platform components relate to OAuth2.

I live in a modern apartment building. It’s a very nice place – pet friendly, upscale furnishings, prime location. One of the best parts about my apartment building, though, is that it has electronic locks available for all the doors. This is pretty similar to most new hotels; each door opens only by using a key card that was issued by the front-desk. The thing that sets it apart from hotels is that it isn’t just the main apartment door that is opened by a key card – each of the inside doors is too. Every internal door in the entire building will only open for you if your key card is authorized for it.

Surprising thing to consider the best feature, right? You might think having doors like this is actually inconvenient and unnecessary – what value is there to having such a locked-down home? What is wrong with just using a plain-old key to open the front door? Let me explain some of the advantages that this door setup offers.

The other day I was walking through the lobby and I noticed that there was an item on the community bulletin board – an advertisement for “Clint’s Dog-Walking Service”. For a small fee, this company offered to make regular stops up to my apartment to pick up my dog (Fido) and take him for walks, whether I’m at home or not. I felt bad for leaving my pooch at home all day while I was at work, so this sounded like a great deal! I called them up for a trial.

This was a small company, and so they sent Clint himself to meet me in the lobby. I filled out the paperwork for my initial trial and then we walked up to the front-desk for Clint to get his key card to my place. The attendant working the desk was named Amy. The first thing Amy needed to see from me was my driver’s license – she wanted to make sure I really was a tenant in the building and also find out which apartment was mine. Next, as is building policy for all key cards issued to non-tenants, Amy asked Clint for his company information along with which doors of mine he would like to be able to open – it’s important that these details are on file with building management, for liability purposes.

Once she was able to verify that Clint’s company was properly registered, she had me look over a form listing the doors that Clint was asking permission to access. For his dog-walking service, he only needed to open my front door and the “dog room” (like I said, this is a very pet-friendly apartment building). I certainly didn’t want him to be able to open my bedroom or office door – he has no business in there, especially when I’m not at home! Fortunately he was only asking for the doors he needed, so I signed Amy’s form. She filed this away for record-keeping and then produced a brand-new key card, which she then handed over to Clint. This key card was only good for a month; this is another building policy designed to reduce the risk of it getting lost or stolen.

Clint then started his regular service walking my dog. Every time he opened one of my doors, the software managing the door logged his entries. I had peace of mind knowing that he could enter my apartment but only to the areas I had approved. I was very happy with the convenience of the whole thing and confident that my privacy was secure.

After the first month, his card expired and so he stopped by the front-desk for a new one. Amy checked to make sure that he was still allowed access; since I was apparently happy with the service at this point (as far as Amy could tell), there was no reason to refuse his request for a new card. Service continued uninterrupted.

Sadly, I eventually decided that Clint’s service wasn’t really worth the money he was asking. In addition, I was working from home more so I didn’t leave my dog alone as often. I contacted Clint and told him I wanted to cancel my account. I also called up Amy at the front-desk and told her that I would like to deactivate Clint’s current key card, and also prevent him from getting any more cards in the future.

This is why my apartment building really is awesome – if I had an old-school physical key and lock on my door, I would have had to make a copy of my key for Clint. In that case, I would have had no idea when he came and left, which rooms he went into, or if he made any other copies of that key for anyone else. When the time came for me to cancel his service, I would have had to take his word for it that he hadn’t made any additional copies of my key when I asked for it back. To have complete peace of mind that he couldn’t come back in without my approval I would have had to change the locks on my door (and if I had changed the locks, anyone else that I had given a key would need to get a new one). These are major problems! I would have never accepted that much hassle and risk if I had been using an old door lock. As it turns out, Clint’s business was really only possible in an environment where I can control these factors.

This is not really my apartment building, it’s OAuth2. This analogy explains exactly why OAuth2 was created and covers the basic way it works.

Before OAuth2, when you needed to give software services access to your account to do things on your behalf you had to give that service your username and password. This is exactly like the physical door key – there is no way to tell whether the agent accessing your data is a third party doing so on your behalf rather than you doing it yourself. As with the physical key, they would have complete access to everything in your account (similar to how a person with a single physical key to the main apartment door would have access to everything inside). If you want to cancel your service, you would need to change your password to be sure they wouldn’t be able to use it again without your permission.

OAuth2 solves this in the same way that my fictitious apartment building solves the physical key problem.

The apartment you wish to visit is an OAuth2 “resource“. Every apartment has an owner; in OAuth2, every resource has a “resource owner” that is authorized to grant access to it. These are the users in your systems; their data are the resources. ForgeRock Identity Management defines an API for operating on user data that may be exposed in this context.

Just how my apartment building replaced physical keys with electronic key cards, in OAuth2 usernames and passwords have been replaced with “access tokens“.

Similar to opening an apartment door with a key card, you request resources using an access token. Likewise, in the way that you would expect a key card to only be able to open certain doors, access tokens are only usable for specific things. In OAuth2, the particular things an access token is capable of being used for are called “scopes“. In my analogy, the doors within my apartment are all coded to require a specific scope (such as “main door”, “dog room”, “bedroom”, “office”, etc…). Any access token presented to one of them which does not have the required scope will fail to open it.

Clint is an example of an OAuth2 “client“. A client is any entity which has been given an access token. Clients vary based on their relationship to the other parties and the ways in which they are able to get an access token. Regardless of these details, all clients essentially behave the same after they have a token – they use it to request protected resources. Clients are the software applications that you bring into your systems to provide benefits to your users. For software without native OAuth2 client capabilites, ForgeRock Identity Gateway offers an easy way to operate as an OAuth2 client.

The building front-desk and associated door tracking software is the OAuth2 “authorization server” (or AS). It is chiefly responsible for issuing access tokens to clients. For that to be possible, some of the same steps that were taken in my story are also required in OAuth2. For example, by presenting my driver’s license I was able to “authenticate” to the front-desk; OAuth2 authorization servers also require an authentication step (usually a username and password prompt but often other prompts too). After Amy at the front-desk checked my ID, she then looked up the details for Clint’s company. This is part of OAuth2 as well – the client needs to be registered with the AS before any tokens are issued to it. The client is responsible for telling the AS which scopes it would like, similar to the way Clint told Amy which doors he wanted to be able to open. The AS shows the resource owner a list of those scopes, as a means of obtaining informed consent regarding what the client will be able to do with their token. If the resource owner approves, then the AS returns the access token to the client. ForgeRock Access Management implements the role of the authorization server.

Every time the client uses its token to request a protected resource, there is a check made by the software protecting the resource (in OAuth2 terms, this software is called a “resource server“) to verify that the token is legitimate, not expired, and has the necessary scopes for the request. This is called “token introspection“. Usually, token introspection involves a call to the AS that issued the token. In the same way that the door checks with the building management software when a key card is presented, this is something that happens without the client’s involvement. The client only sees if the request is granted; the door either opens or it doesn’t. ForgeRock Identity Gateway offers an easy solution to act as a resource server, with several means of token introspection available to choose from.

Access tokens expire in the same way that the key cards were described. Depending on the agreement made between the client, the resource owner, and the AS there may be a way for the client to obtain new access tokens without having to ask the resource owner every time it expires. This is just like the way Clint was able to get a new key card from Amy after his first expired. In OAuth2, this process involves the “refresh token“. The refresh token is only usable to get new access tokens; it’s not usable directly to access protected resources. The point of this token is to try to limit the risk of lost or stolen access tokens. Both refresh tokens and access tokens can be revoked by the resource owner on the AS, in the same way that I described calling Amy when I wanted to cancel my service with Clint. Revoked access tokens will be detected during token introspection, which will prevent their continued use.

OAuth2 enables new businesses and practices to thrive in a trusted environment where it would be impossible otherwise. By establishing this consent relationship between the clients and the resource owners, people have the tools necessary to maintain their privacy and security to the degree they demand. The ForgeRock Identity Platform is the best means to offer that relationship – go forth and build your own OAuth2 apartment building!

Special thanks to Aaron Parecki for the basic “access token as hotel key card” analogy, which I heard him mention in a user group presentation similar to the one he gives here: Using OAuth2 and OpenID Connect in your Applications.

Update: Read the follow-up which describes how the OAuth2 Apartment Building relates to the OpenID Connect Neighborhood

Documenting ForgeRock DS HTTP APIs

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

ForgeRock DS directory servers do not enable the CREST APIs to directory data by default, since you must first adapt the REST to LDAP mapping for your data. To get started with REST to LDAP, see To Set Up REST Access to User Data.

In the end, make sure that the API is enabled before trying to read its descriptor. For example, you can enable the default /api endpoint with the following command (adapted for your installation):

/path/to/opendj/bin/dsconfig \
 set-http-endpoint-prop \
 --hostname opendj.example.com \
 --port 4444 \
 --bindDN "cn=Directory Manager" \
 --bindPassword password \
 --endpoint-name /api \
 --set enabled:true \
 --no-prompt \
 --trustAll

The ForgeRock DS product does not currently include an API explorer, but you can get the OpenAPI-format API descriptor for any or all CREST endpoints. You pass the _api query string parameter to the endpoint. The resulting OpenAPI descriptor is a JSON document. Get available CREST APIs for directory data with a request to the /api endpoint:

curl -o ds.json -u kvaughan:bribery http://localhost:8080/api?_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 ds.json as the descriptor:

DS 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:

DS Swagger Editor.png

For more information, see Working With REST API Documentation.

Documenting ForgeRock IG HTTP APIs

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

The ForgeRock IG product does not currently include an API explorer, but you can get the OpenAPI-format API descriptor for any or all endpoints. You pass the _api query string parameter to the endpoint. The resulting OpenAPI descriptor is a JSON document. For example, you can start IG in development mode as described in Starting IG, and then get all available APIs with a request to the /openig/api endpoint:

curl -o ig.json http://localhost:8080/openig/api?_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 ig.json as the descriptor:

IG 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:

IG Swagger Editor.png

For more information, see Understanding IG APIs With API Descriptors.

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