Protocol Connection

Add Protocol Connection


All Protocol Connection share a number of identical settings, which will be explained below, but some of them will also have a number of additional configuration settings used for establishing the connection to the external party (IdP or RP). In order to see these additional settings you will first have to save a connection with the basic settings explained in this chapter; then open the connection for editing again.

protocol connection 1

Name: A name that identifies the Protocol Connection.

Description: A description of the connection for internal administrative purposes only.This field supports localization.

Enabled: If a connection is disabled, the related Relying Party will not be able to use Safewhere*Identify as IdP.

Use Persistent Pseudonym: Federation with persistent name IDs establishes a permanent relationship between a user on an Identity Provider and a user on a Relying Party or users on an affiliation of Relying Parties. The persistent name ID is used by an Identity Provider and a Relying Party as a common name for a single user. If this name ID for a user is the same for multiple Relying Parties, the Relying Parties are said to be affiliated or belong to an affiliation group. Use this kind of federation to link accounts out-of-band, but without using identifiers that can be traced back to a specific user. This increases the security of your systems by preventing eavesdroppers from determining identities on the basis of name ID formats that pass logon IDs or e-mail addresses.

Ignore Authentication Method of Choice: When a user initially is asked to authenticate and there are multiple possible authentication methods to choose among, then the user will be asked which one he wants to use for logging in. Once selected, then all future logins will automatically assume that this is the authentication method of choice for him. If you want to force the user to select the preferred authentication method each time, please tick this checkbox.

Owner Organization: By default, the owner organization will be set to the organization of the user who created the connections. If you wish a different organization to own the connection, you can set it here. A user will only be offered to change it to his organization or any sub-organization of it.

The next settings described in this chapter all have an influence on how claim values are set in the claims pipeline. All of them can thus be said to be claim filters. Any request using the selected Protocol Connection will thus be subjected to the claims filters of it as specified in the following:

Connection Dependency: this settings allows user to specifiy what authentication connections to be used with this Protocol Connection. User is also able to set the priority of Authentication Connection (which is used for picking up session when multiple sessions exist) by changing its index in the list using Up/Down buttons.

protocol connection 2

Home Realm Discovery: this settings allows user to specify what HRD mechanisms to be used with this Protocol Connection. User is also able to set the priority of mechanism by changing its index in the list using Up/Down buttons – which is used to decide what mechanism is called during HRD processing. There are two groups of HRD rules: Standard and default mechanisms.

protocol connection 3

Current HRD mechanisms:

  • Whr parameter: see description below.
  • Persistent cookie: persistent cookie discovery.
  • Show tailored IDPs list from CDC: Even when CDC is used, there may be multiple Idps are discovered from CDC. When this option is not checked, Safewhere*Identify simply picks the first appropriate Idp. Otherwises, it shows all appropriate Idps in a selector page so that users can pick one
  • Common domain cookie:CDC discovery.
  • IP-based HRD: When an SSO request comes from an IP-address matching that set on an Authentication Connection – and this mechanism is enabled -then Identify will use the “IP-based filter for Home Realm Discovery”to find the one that is prioritized. If the value matches with more than one of the Authentication Connection, then the one chosen will be the one that is indexed lowest in the Connection Dependency list. If none match, then IP-address will not be used for HRD.
  • Auto HRD:When a user is redirected to Safewhere*Identify, the system can detect if he or she has already logged in to an upstream identity providers such as Facebook, Google, or ADFS 2.0 in the same browser session and thus automatically use the corresponding connection to grant the user access to the relying party he or she wants to visit.

There are a few other settings related to Auth HRD explained below:

  • Disable automatic Auth selection if not supported by all login modules: if this option is checked and there is an Authentication Connection, which does not support auto HRD, the auto HRD mechanism will not be used.
  • Auto Home Realm Discovery processing timeout: (seconds). It may take a while to process through iframes of the login. This value is used to stop the auto HRD process when the set time is exceeded.
  • Allow user to override Auto HRD: when this option is checked, then a button will be offered that says; “If you want to ignore and continue, click here!”. It will allow a user to skip auto HRD processing manually.
  • Option for processing Home Realm Discovery when error happens: determine what option to process when fatal error happens. Two options are offered:
  • ProceedToNextMechanism: when fatal error happens, proceed to using the next lower priority mechanism.
  • ProceedToDefaultMechanism:when fatal error happens, proceed to using default mechanisms.
  • Default HRD mechanisms: offer three possible choices for the HRD mechanism:
  • Determine single authentication connection:determine each authentication login status.
  • Identify-initiated common domain cookie:Identify-initiated cookie discovery.
  • Show log on picker: Show Selector page to pick up an Authentication Connection.

Claim Pipeline: The Claim Pipeline of the Protocol Connection consists of a number of Transformation steps that you can select. Only claim transformations which belong to the organization in the allowed-to-see organizations of current logged user are displayed. Each Transformation step will alter the claim set of the token before handing it on to the next step. You can choose to add any of the Claim Transformation objects that are added to the system. To read more on adding Claim Transformation objects please click here. To relate a Claim Transformation object to the connection’s Pipeline, choose it from the dropdown and click “Add”. Make sure to order the objects so transformations are done in the right order. The higher in the list the earlier the Transformation step will be executed.protocol connection 4

 

Remember Consent: If you wish to make it possible for the users to choose to skip the consent step when logging in given that they gave consent during the initial login, set it to ‘True’. The consent choices they made will be saved and used for their future authentications for this Protocol Connection.

Consent claims sets: The consent claims set of the Protocol Connection consists of a number of claim sets that you can select. You can choose to add any claims set that are added to the system. To read more on adding Claims set objects please click here. To relate a Claims set object to the connection’s consent, choose it from the dropdown and click “Add” or select the added claims set from the selected added claims set list and click “Remove” to remove it.

protocol connection 5png

Scopes for consent:Consent scopes are relying party specific data for the user that can be requested by the RP from the with the Resource Server/Protected Resource.

protocol connection 5png

To relate a scope object to the connection’s consent, click “Add”button:

protocol connection 7

  • Name: Specify a name for the scope that will make it easy to recognize when adding to the “Scopes for consent” on the Protocol Connection s.
  • Code: Specify the code for the scope.
  • Description: Specify the description that will make it easy to recognize when viewing on my consent or consent page.
  • Is the scope required for user to authenticate?: When a scope is required then the user must agree to it before he can continue logging in.

Note: Name and code must be unique for the connection.

Authentication list view name:Specify what view should be used in place of the default view to display associated authentication connections.To activate this feature, put your specified view at the locations~/Views/PlugIn/ or ~/Views/Shared/in the Runtime folder and input the view name (not including “cshtml” file type) on the “Authentication list view name” field of the Protocol Connection.

Present the login selection page if no prior Relying Party specific selection has been made:Instead of having a cookie with one value common for all Relying Parties, the cookie will store a login selection choice per Relying Party. This setting allows the administrator to choose whether the user should be offered to select another authentication method than the one they are currently logged in with albeit in a session with another Relying Party. Presenting such a choice is important in the case, where the choice of authentication method will have an impact on the authorization rights of the user. It is also possible to just choose – as was the case in earlier versions – that SSO will be carried out whenever possible.

Now let us take a look at the different configuration settings that exist for the different Protocol Connection types.

SAML 2.0


SAML 2.0 is a populardata format for communicating claims between a claims provider and a relying party.

The configuration settings offered by this Protocol Connection type are:

  • ­­When Persistent Pseudonym is used, Identify offers user ability to validate that the NameIDPolicy element must be present with the AllowCreate attribute set to “true” and the Format attribute set to “urn:oasis:names:tc:SAML:2.0:nameid-format:persistent“. If validation is enabled and the RP settings does not satisfy this, Identify will respond with a ‘urn:oasis:names:tc:SAML:2.0:status:Responder’status code to SAML RP.

saml  1

  • Validate if allow create is true when persistent pseudonym is used: To enable validation for AllowCreate and NamId Format, check the option

saml 2.0 2

  • Entity ID: The entityID attribute is the unique identifier of the identity provider.

This signing certificate element specifies the signing certificate used by the Protocol Connection. This certificate is used by Safewhere*Identify to sign the communication to the Relying Party. The potential elements are:

  • Find value: The value of the attribute that is used to Safewhere*Identify the certificate, e.g. its subject or thumbprint.
  • Get certificates button: Allow users to select a new cert.
  • Find type: Specifies which certificate attribute that will be used to Safewhere*Identify the certificate. A common way to locate a certificate is to search for its subject s distinguished name or its thumbprint. The authentication connection will use the first certificate that matches the specified search criteria.Possible values are: FindByThumbprint, FindBySubjectName, FindBySubjectDistinguishedName, FindByIssuerName, FindByIssuerDistinguishedName, FindBySerialNumber, FindByTimeValid, FindByTimeNotYetValid, FindByTimeExpired, FindByTemplateName, FindByApplicationPolicy, FindByCertificatePolicy, FindByExtension, FindByKeyUsage, FindBySubjectKeyIdentifier.
  • Store location: The location of the certificate store to use.Possible values are: CurrentUser, LocalMachine.
  • Store location name: Specifies which certificate store the certificate is placed in.
  • Signing certificate is in store?: Auto-set value. Checked state indicates that the certificate is found in the specified location.

This encryption certificate element specifies the encryption certificate used by the Authentication Connection. This certificate is used by Safewhere*Identify to sign the communication to the Relying Party. The potential elements are:

  • Find value: The value of the attribute that is used to Safewhere*Identify the certificate, e.g. its subject or thumbprint.
  • Get certificates button: Allow users to select a new cert.
  • Find type: Specifies which certificate attribute that will be used to Safewhere*Identify the certificate. A common way to locate a certificate is to search for its subject s distinguished name or its thumbprint. The authentication connection will use the first certificate that matches the specified search criteria. Possible values are: FindByThumbprint, FindBySubjectName, FindBySubjectDistinguishedName, FindByIssuerName, FindByIssuerDistinguishedName, FindBySerialNumber, FindByTimeValid, FindByTimeNotYetValid, FindByTimeExpired, FindByTemplateName, FindByApplicationPolicy, FindByCertificatePolicy, FindByExtension, FindByKeyUsage, FindBySubjectKeyIdentifier.
  • Store location: The location of the certificate store to use.Possible values: CurrentUser, LocalMachine.
  • Store name: Specifies which certificate store the certificate is placed in. Possible values are: AddressBook, AuthRoot, CertificateAuthority, Disallowed, My.
  • Encryption certificate is in store:Auto-set value. Checked state indicates that the certificate is found in the specified location.

Identify currently supports up to 3 SLO bindings: HTTP-Redirect, HTTP-POST and SOAP. Those bindings are available for both Protocol Connection and Authentication connection.If a party (RP /IdP) supports all 3 bindings, they will be imported into the respective binding sections, HTTP-Redirect must exist.

saml 2.0 3

 

Note: in order to make SOAP logout works well, the following setting in System set up must be checked as SOAP logout requires a database read for *every* requests coming to Runtime which obviously slows things down a little bit. Meanwhile, most of Identify deployments don’t use SOAP logout. As a result, the setting is introduced for the sake of performance optimization

saml 2.0 4

  • Assertion consumer service binding: the binding that Safewhere*Identify should use to send sign on responses to the involved RP. Incase HTTP-Artifact is used, Identify will:
    • Return an Artifact instead of a direct SAMLResponse message.
    • Expose an artifact resolution service where an SP can use to exchange an artifact for a SAMLResponse.
  • Assertion consumer service location: the endpoint to which Safewhere*Identify should send sign on responses.
  • Subject confirmation data recipient: Specifies the value to set to the recipient property of assertion’s SubjectConfirmationData. Relying party can then use this value to validate if the token is meant to send to it. EntityIdentifier is used as the default value for this setting. Some RPs such as AD FS 2.0 requires that this value is set to its single sign on endpoint.
  • Set response’s issuer: Speficies if the Issuer value of an assertion should be set which is required by some RPs.
  • Validate AssertionConsumerServiceUrl in AuthnRequest: When this is checked, Safewhere*Identify performs validation against AssertionConsumerServiceUrl of incoming AuthenRequest messages.
  • Token life-time: Specifies how long a token which Safewhere*Identify issues remains valid. Technically speaking, it affects Conditions.NotOnOrAfter value.
  • Show tailored list from CDC: Even when CDC is used, there may be multiple Idps are discovered from CDC. When this option is not checked, Safewhere*Identify simply picks the first appropriate Idp. Otherwises, it shows all appropriate Idps in a selector page so that users can pick one.
  • Secure hash algorithm: Identify provides support for both SHA1 and SHA256 algorithm.

The below configuration setting is offered for OIO IDWS Identify STS (for more details, please go to the following page: https://safewhere.zendesk.com/entries/49249219-OIO-IDWS-Identify-STS-setup).

  • Audience restriction: List of valid entity IDs. The entity IDs are separated by “;”. This audience restriction is set to the issuerthat is used to issue bootstrap token (aka ActAs token).

Safewhere*Identify provides some revocation methods to determine the status of in use signing and encryption certificates. Online Certificate Status Protocol (OCSP) and Certificate Revocation List (CRL) are mechanisms to be used with settings are configured in the Connections detail. Revocation Checks can be set for:

  • Signing certificate revocation check
  • Encryption certificate revocation check

The values that can be set for the above are:

  • None: Revocation checking is done.
  • CheckEndCert: Revocation checking is done on the end certificate and only the end certificate.
  • CheckEndCertCacheOnly: Revocation checking is done on the end certificate and only the end certificate. Revocation checking only accesses cached URLs.
  • CheckChain: Revocation checking is done on all of the certificates in every chain.
  • CheckChainCacheOnly: Revocation checking is done on all of the certificates in every chain. Revocation checking only accesses cached URLs.
  • CheckChainExcludeRoot: Revocation checking is done on all certificates in all of the chains except the root certificate.
  • CheckChainExcludeRootCacheOnly: Revocation checking is done on all certificates in all of the chains except the root certificate. Revocation checking only accesses cached URLs.

Safewhere*Identify can function as a proxy for another identity provider. An identity provider proxy enables you to create structures of trust relationships that ultimately simplify the management of your service providers:

  • Enable proxy: When enabled, all the validation rules will be applied. In addition, the AuthnRequest – which Identify sends to upstream IdPs – will contain proxying attributes.
  • Requester Id: Requester Id of the service provider. This value may be included in AuthnRequest sent to upstream IdPs when “Use the RequesterId above for proxied AuthnRequest”is ticked.It should be in the form of a URI, e.g.urn:safewhere:company:dk
  • Use the RequesterId above for proxied AuthnRequest:When this setting is True, the AuthnRequest, which Identify sends to upstream IdPs, will use Requester Id valueinstead of the value it gets from service provider.
  • Do not include authentication authorities from upstream IdPs: By default, when proxying is used, the response sendt to the original service provider needs to have AuthenticatingAuthority attribute. This option allows for omitting that piece of information.

There are 2 configuration settings for the SAML 2.0 attributes service: (Test client sample can be found in Zendesk)

  • Attribute name which specifies subject claim type: Specifies the attribute that defines the subject claim type.
  • Default subject claim type: Ifit is not possible to extract subject claim type from the request, this value will be used as subject claim type.

Requested authentication context method class is used to specify what type of authentication should be used to authenticate a user. As an RP, Safewhere*Identify must check if an assertion from an Identity Provider contains any AuthenticationStatement that meets the method class it formerly specified in an AuthnRequest.

  • Default requested authentication context class: Default value is the X509 class.
  • Always use default requested authentication context class: When this is set to true, assertions which Safewhere*Identify return to Relying Parties always have the default class. Default value is TRUE.
  • Evaluate requested authentication context: Specifies if Safewhere*Identify should check whether it has any authentication connection that can fulfill the requested authentication context of an AuthnRequest.
  • SAML response signing: Specifies what parts of a log in SAMLResponse message should be signed. There are 3 options: MessageOnly, AssertionOnly, and MessageAndAssertion.
  • Do not encrypt assertions: Specifies if issued assertions should be encrypted.
  • Set SessionNotOnOrAfter: A date sent to the requesting party, that specifies the date and time after which the session will no longer be valid. The value in this field is set in minutes so the value sent will be current time + SessionNotOnOrAfter.

Common Domain Cookie (CDC) section: is a secure browser cookie scoped to the common domain. For each browser user, this cookie stores a history list of recently visited IdPs. The name and value of the cookie are specified in the IdP Discovery Profile. Identify supports both read and write methods:

Settings in Identify*Admin for SAML 2.0 Protocol Connection:

saml 2.0 5

To enable writer, fill in the CDC write path to “Common domain cookie writer” field

  • When the writer is configured, the Identify IdP will append its entityID to the IdPs list of CDC after SAML RP logins successfully.

To enable reader, fill in the CDC read path to “Common domain cookie read” field

  • When the reader is configured, for every SAML request from this RP , Identify will read from the CDC’s cookies and pick up the last IdP in the IdPs list for authenticating.

Note: The IdentifyCDC package can be found in the installation folder, named “CDC”

WS-Federation


WS-Federation is a populardata format for communicating claims between a claims provider and a relying party.

This protocol can be used for both passive federation (browser-based) or active federation (Windows client-based). Typical examples of active clients are Windows applications, Java applications, Windows services, or even clients which are hosted in IIS, but use WCF to ask Identify for security tokens. The difference is that ‘active STS’ does not require you to fill in the fields “passive requestor endpoint” and “sign out reply endpoint”.

The configuration settings offered by this Protocol Connection type are:

  • Entity ID:The entityID attribute is the unique identifier of the identity provider.
  • Passive requestor endpoint: Specifies the endpoint of an RP to which Safewhere*Identify sends log in responses.
  • Sign out reply endpoint: Specifies the endpoint of an RP to which Safewhere*Identify sends log out responses.
  • Find value: The value of the attribute that is used to Safewhere*Identify the certificate, e.g. its subject or thumbprint.
  • Find type: Specifies which certificate attribute that will be used to Safewhere*Identify the certificate. A common way to locate a certificate is to search for its subject’s distinguished name or its thumbprint. The authentication connection will use the first certificate that matches the specified search criteria.Possible values are: FindByThumbprint, FindBySubjectName, FindBySubjectDistinguishedName, FindByIssuerName, FindByIssuerDistinguishedName, FindBySerialNumber, FindByTimeValid, FindByTimeNotYetValid, FindByTimeExpired, FindByTemplateName, FindByApplicationPolicy, FindByCertificatePolicy, FindByExtension, FindByKeyUsage, FindBySubjectKeyIdentifier.
  • Get certificates button: Allow users to select a new cert.
  • Store location: The location of the certificate store to use.Possible values are: CurrentUser, LocalMachine.
  • Store name: Specifies which certificate store the certificate is placed in.Possible values are: AddressBook, AuthRoot, CertificateAuthority, Disallowed, My.
  • Use Saml 1.1 token profile: Specifies in case 1 token format is needed.

The below configuration settingsare offered by for OIO IDWS Identify STS:

  • Audience restriction: List of valid entity IDs. The entity IDs are separated by “;”. This audience restriction is set to the issuerthat is used to issue bootstrap token (aka ActAs token).
  • Support OIO WS-TrustProfile: When ticked, the OIO IDWS profile is handled by the connection.
  • Bootstrap token timestamp: it is the timeline in minutes for bootstrap token.Its default value is 60 minutes.
  • Assurance level required: The minimum required assurance level when issuing bootstrap token. Its default value is 0.
  • Assurance level claim type: The claim typeused for storing assurance level issued on bootstrap token.Default is “urn:oasis:names:tc:SAML:attribute:assurance-certification”
  • Bootstrap tooken trusted issuers: The list of valid trusted issuers who issued bootstrap token.
    • Find value: The value of the attribute that identifies the certificate, e.g. its subject or thumbprint.
    • Find type: Specifies which certificate attribute that will be used to identify the certificate. A common way to locate a certificate is to search for its subject’s distinguished name or its thumbprint. The authentication connection will use the first certificate that matches the specified search criteria.Possible values are: FindByThumbprint, FindBySubjectName, FindBySubjectDistinguishedName, FindByIssuerName, FindByIssuerDistinguishedName, FindBySerialNumber, FindByTimeValid, FindByTimeNotYetValid, FindByTimeExpired, FindByTemplateName, FindByApplicationPolicy, FindByCertificatePolicy, FindByExtension, FindByKeyUsage, FindBySubjectKeyIdentifier.
    • Get certificates button: Allow users to select a new cert.
    • Store location: The location of the certificate store to use.Possible values are: CurrentUser and LocalMachine.
    • Store name: Specifies which certificate store the certificate is placed in.Possible values are: AddressBook, AuthRoot, CertificateAuthority, Disallowed, and My.
    • Add/Update/Cancel button:Allowsuser to manage the trusted issuers.

The below configuration setting is offered by for STS issuedtokensymmetricbasic256sha256 endpoint.

  • Received Security Token Encryption certificate: Thecertificate element specifies the encryption certificate used by the issuedtokensymmetricbasic256sha256 protocol.
    • Find value: The value of the attribute that is used to Safewhere*Identify the certificate, e.g. its subject or thumbprint.
    • Find type: Specifies which certificate attribute that will be used to Safewhere*Identify the certificate. A common way to locate a certificate is to search for its subject’s distinguished name or its thumbprint. The authentication connection will use the first certificate that matches the specified search criteria.Possible values are: FindByThumbprint, FindBySubjectName, FindBySubjectDistinguishedName, FindByIssuerName, FindByIssuerDistinguishedName, FindBySerialNumber, FindByTimeValid, FindByTimeNotYetValid, FindByTimeExpired, FindByTemplateName, FindByApplicationPolicy, FindByCertificatePolicy, FindByExtension, FindByKeyUsage, FindBySubjectKeyIdentifier.
    • Get certificates button: Allow users to select a new cert.
    • Store location: The location of the certificate store to use.Possible values are: CurrentUser, LocalMachine.
    • Store name: Specifies which certificate store the certificate is placed in.Possible values are: AddressBook, AuthRoot, CertificateAuthority, Disallowed, My

OAuth 2.0


OAuth 2.0 protocol connection is developed based on OAuth 2.0 framework (http://tools.ietf.org/html/rfc6749) which is used for both authentication and authorization. It supports Implicit and Code flow and can be used as an OpenID connection.

The configuration settings offered by this Protocol Connection type are:

  • Client ID: unique ID of a client – required.
  • Client secret: secret code – required.
  • Redirect URL: redirect URL after successful authentication – required.
  • Application name: name of the application – required.
  • Application logo URL:URL to a logo file of the application – optional.
  • Set the audience field of tokens which are issued for the application:.
  • Allow implicit flow: enable if allow implicit flow for this connection.
  • Allow code flow:enable if allow code flow for this connection. Must be checked to use this connection as OpenID Protocol Connection.
  • Use as OpenID Connect: enable to user this connection as OpenID. When this option is enabled, user can see the claim sets on the consent page.
  • JWS algorithm: the algorithm used for for JWT access tokens. Values can be: RSASigning, HMACSymmetric.
  • Symmetric signing key:Hex-encoded key used to sign JWT when HMAC JWS is chosen.

Encryption Certificate settings:

  • Find value: The value of the attribute that is used to Safewhere*Identify the certificate, e.g. its subject or thumbprint.
  • Find type: Specifies which certificate attribute that will be used to Safewhere*Identify the certificate. A common way to locate a certificate is to search for its subject’s distinguished name or its thumbprint. The authentication connection will use the first certificate that matches the specified search criteria.Possible values are: FindByThumbprint, FindBySubjectName, FindBySubjectDistinguishedName, FindByIssuerName, FindByIssuerDistinguishedName, FindBySerialNumber, FindByTimeValid, FindByTimeNotYetValid, FindByTimeExpired, FindByTemplateName, FindByApplicationPolicy, FindByCertificatePolicy, FindByExtension, FindByKeyUsage, FindBySubjectKeyIdentifier.
  • Get certificates button: Allow users to select a new cert.
  • Store location: The location of the certificate store to use.Possible values are: CurrentUser, LocalMachine.
  • Store name: Specifies which certificate store the certificate is placed in.Possible values are: AddressBook, AuthRoot, CertificateAuthority, Disallowed, My.

Other settings for this connection:

  • Token security mode:base on our developer’s research, MS’ JWT handler only supports SigningOnly.
  • Token life time (minutes):how many minutes before the token is expired.
  • Allow refresh token:Whether access tokens will be issued with refresh tokens.
  • Refresh token life time (minutes): how many minutes before the refesh token is expired.
  • OpenID Connect logout redirect URL:redirect URL after successful SLO – required.
  • Open auto-generated HMAC button: used to generate the HMAC Symmetric signing key, key can be 32-byte, 48-byte or 64-byte. User then can either copy the key and pasted to configuration or check the approriated checkbox and click Select key to apply it.

oauth

OpenID


Safewhere*Identify’s OpenID protocol connection supports OpenID 2.0, which is widely adopted (http://OpenID.net/specs/) in the community. Using the OpenID 2.0-based protocol connection, it is possible for Safewhere*Identify to act as an OpenID Identity Provider. Thus, users can identify themselves via the multitude of different authentication methods that are supported by Safewhere*Identify and access OpenID 2.0-based web sites and online applications.

The specifications that have been implemented for OpenID can be found via the following links:

  • OpenID authentication 2.0 (http://OpenID.net/specs/OpenID-authentication-2_0.html)
  • OpenID simple registration 1.1 extension (http://OpenID.net/specs/OpenID-simple-registration-extension-1_1-01.html)
  • OpenID provider authentication policy extension (only implementation of “max_auth_age” – http://OpenID.net/specs/OpenID-provider-authentication-policy-extension-1_0.html)
  • OpenID attribute exchange (Fetch requests only – http://OpenID.net/specs/OpenID-attribute-exchange-1_0.html)

There are several steps that will need to be carried out in order to set up an OpenID Protocol Connection:

Step 1: Create a new free claim to be used to store the OpenID identifier for each user.

Go to the claims list to create the claim in which this identifier will be stored. You can e.g. call the new claim “OpenIDidentifier”.

openid 1

Step 2: Inform Safewhere*Identify that this claim is used as the OpenID identifier.

Go to the system setup tab to do this. Simply select “OpenIDidentifier” from the dropdown list.

openid 2

  • This claim’s value is unique across all the Identify users. It is auto-generated as a random id in case a user is authenticated by OpenID provider without the initial value.The generated random id is “OpenID[GUID]”. Could as an example be: https://[tenant url]/runtime/OpenID/op/OpenIDfdbbea47-80c8-4ef3-aad6-7d9b4cbb30f5
  • The OpenID identifier is defined as https://[tenant url]/runtime/OpenID/op/[OpenID identifier claim’s value]

Step 3: Set up an “OpenID protocol connection” for each relying party to use it.

Below is explained the different configuration options for each OpenID protocol connection:

openid 3

 

Redirect URL: Where the user will be redirected back to after succesfull authentication. Required.

Allow redirect to http URL:Set to true if it should be allowed that the user is redirected back to an http URL.

Allow immediate mode:If the end user is not to beable to interact with the OpenID Provider then this should be set to True.

Step 4: Import the claim set which is used for Simple Registration Extension

OpenID Simple Registation is an extension to the OpenID Authentication protocol that allows for very light-weight profile exchange. It is designed to pass eight commonly requested pieces of information when an End User goes to register a new account with a web service. It supports to getEmail, Fullname, DOB, Gender, Nickname, Postcode, Country, Language, and Timezone:

For easy creation for these claims, we can go to the claim list on the Admin site of Identifyand import the claims using the “Import Predefined Claim Types”feature.

openid 4

Choose “Claim Type definitions for OPENID PROVIDER SIMPLE REGISTRATION CLAIMS SET”.

openid 5

Here are the claims that are added after import:

openid 6

Once these have been set up it means that Identify will need to map its claim types to these through the use of claim transformation so that OpenID RP can receive them.

To learn more about OpenID protocol, please click here.

Was this helpful ?Good Somewhat Bad