a) General

Subsequent pages contain general information of the Implementation.

Documentation Practices

In this documentation we try not to repeat detailed information that is already detailed elsewhere. In aspects, where better detailed information can be found in standard specifications or widely trusted party, link to that documentation is included. We try to make links as specific as possible. Where referred documentation facilitates it, exact chapter or another anchor in the text is included. If this is not possible, we try to add exact textual reference in connection to the link.

Internet is dynamic and evolving thing and while semantic web has not really realised, links fail sometimes. If you find broken links, please help us to fix them with Pull Requests or contact us.

Clarification of Used Terms

We try to follow mainly terms defined in OIDC Specification. However, there is some variance.

IdP

We refer to the IdP service as an instance of an IdP entity and in some situations your own deployment as the IdP, although in OpenId Connect terms the entity performing the authentication of the users is referred with term OpenId Provider (OP). The term IdP dates back to older times when SAML2 was the prominent protocol for authentication. For concistency we still use the old term in this documentation although it most often refers to OIDC OP.

RP or Rp

With the term Relying Party (RP) we refer to the Service Provider (SP) that is protecting the access to your application or service. RP is used as a term in both OIDC and SAML worlds, although in SAML the service is most often referred as the SP.

In illustrations RP is written with lowercase p (Rp). This is because of a technical limitation in the PlantUML renderers that we use. They produce horrific results when both letters in the acronym are uppercase.

In some situations the terms RP, SP, or PEP might be used interchangeably. The term Policy Enforcement Point (PEP) also refers to a technical entity, product or implementation that protects the access to application by predefined policies. As the purpose of all these are somewhat similar, these terms appear in similar use although according to a case in hand with a slightly different context.

Documentation Source Code

This book is created by Documentation as Code. The source code of the documentation is available in GitHub for adding Issues and Pull Requests.

Where convenient, illustrations are created with PlantUml.

Please, save trees, don’t print. We expect that this documentation evolves through the time and your printed copy gets old very quickly. Also, paper is made of trees and we love trees. Don’t cut them, but let them harvest excess CO² from the atmosphere.