...

• The JS7 - Identity Services offer management of user accounts for authentication and authorization.
• FIDO is a set of authentication standards based on the work of the FIDO Alliance and W3C.
  • The underlying WebAuthn API is used by the FIDO2 protocol, its predecessor FIDO U2F and Passkeys.
  • Users can adjust the Identity Service to work compatible with FIDO2, FIDO U2F and Passkeys.
  • FIDO U2F is limited to use as a second factor with other Identity Services that offer multi-factor authentication (MFA).
• The FIDO Identity Service integration is available from JOC Cockpit:
• As a prerequisite JOC Cockpit has to be set up for JS7 - JOC Cockpit HTTPS Connections.
• Compliant Authenticators can be used, this includes software based Authenticators and hardware based Authenticators such as compliant USB Sticks.
JS7 implements a FIDO Client and Server for use with an Authenticator. JS7 does not ship with an Authenticator.
• Examples for Authenticators include Windows® Hello (Platform Authenticator) and YubiKey® (Roaming Authenticator).

• Display feature availability
  StartingFromRelease 2.6.0

  
  

  Jira
  server SOS JIRA columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 6dc67751-9d67-34cd-985b-194a8cdc9602 key JOC-1546

...

• Security Key is a physical device that can connect using USB, NFC, BLE etc. and that hosts an Authenticator. Examples include YubiKey®, TrustKey® etc. 
• Authenticator is a system that provides credential services such as creating private/public key pairs. Authenticators are available as Roaming Authenticators (=Security Keys) and as Platform Authenticators (=hosted with the user's device or in a cloud service).
• Client is the JOC Cockpit GUI that performs login by use of Authenticator services.
• Relying Party is the JS7 - REST Web Service API that verifies Client signatures to prove the identity of a user.

Identity Service Type

...

Explanation:

• Service Type: FIDO
  • Management of user accounts and private/public keys is performed by the Authenticator
  • The assignment of roles to user accounts is performed by the JOC Cockpit Relying Party.
  • The JOC Cockpit stores user accounts and role assignments: in the JS7 - Database.
  • The JOC Cockpit does not know private keys of user accounts. JOC Cockpit knows the user account's public key that is used to verify authentication requests.
• The FIDO Identity Service identifies the user, not the device used for authentication. To protect the user's privacy no Attestation is performed.

Identity Service Configuration

...

Image Removed

Add Identity Service

...

Image Removed

...

Image Removed

Explanation:

• The Identity Service Name is a unique identifier that can be freely chosen.
• The Identity Service Type can be selected as available from the above matrix.
• The Ordering specifies the sequence in which a login is performed with available Identity Services.
• The Required attribute specifies if the respective Identity Service is mandatory for login to JOC Cockpit.
• The Used as Second Factor attribute specifies if the Identity Service is used as an additional factor in multi-factor authentication with other Identity Services or is used as an Identity Service of its own.
  • The FIDO2 and Passkeys protocol can be used as a single factor or as a second factor in MFA.
  • The FIDO U2F protocol can be used as a second factor in MFA.
• The Identity Service Authentication Scheme allows to select
  • single-factor authentication: FIDO authentication works as the only factor for login with the Identity Service.
  • two-factor authentication: in addition to use of a FIDO protocol a Client Authentication Certificate is required - see the JS7 - Certificate based Authentication article for more information.

Identity Service Settings

...

Image Removed

...

Image Removed

Explanation:

• Attestation
  • When users register a new Security Key then the Authenticator will generate a new public/private key pair. The public key is forwarded to the Relying Party, the private key remains with the Security Key.
    During registration the Authenticator might provide an attestation to the Relying Party. The attestation statement includes information that can be used to verify the authenticity of the Authenticator. The attestation statement is used by the Relying Party to verify that the Authenticator is genuine and to trust the generated key pair.
  • Options: direct, enterprise, indirect, none.
  • For explanations see https://w3c.github.io/webauthn/#attestation-conveyance
• Timeout
  • The time in seconds that is waited for a user's response when being prompted for registration, for example to specify a PIN for the user's Security Key device.
• Transports
  • The Identity Service can limit the ways of communication between the Client and the Authenticator that are acceptable.
  • For example, specifying usb will limit acceptable Authenticators to use of USB Sticks. The Relying Party will deny registration if no matching way of communication is provided by an Authenticator.
  • For explanations see https://w3c.github.io/webauthn/#enum-transport
• User Verification
  • User verification includes that a user performs a gesture during registration and authentication to prove the user's presence and consent.
  • Possible values include:
    • Preferred: User verification is optional. The Client should perform user verification if capabilities are given.
    • Discouraged: User verification should be avoided by the Client. However, it can take place if the Client performs this operation.
    • Required: User verification is mandatory. The Relying Party will deny registration and authentication if no user verification is performed by the Client.
E-Mail Settings
• Tab Connection: This tab holds settings for connections to the mail server.
  • Job Resource: A job resource has to be selected from the inventory that holds settings for the connection to the mail server, for download and explanation see JS7 Job Environment Variables, Job Resource eMailDefault
  • Content Type:  The values text/html and text/plain are applicable for HTML mail and text mail.
  • Charset:  The character sets ISO-8859-1 and UTF-8 are frequently used.
  • Encoding: The ISO-8859-1, UTF-8 and 7-bit encodings are frequently used.
  • Priority: The values Normal, Low, High are applicable.
Tab Confirmation E-Mail: This tab holds a mail template that is used to ask users to follow a link in order to confirm their mail address.
Image Removed

• Send Mail to confirm e-mail address: If the checkbox is checked then related mails will be sent.
• Subject: The subject of the mail. Users can modify the subject at their will.
Body: The body of the mail. Users are free to adjust the mail body.
• By default an HTML template is provided that holds the following variables that will be substituted when sending mail:
  • ${REGISTRATION_EMAIL_ADDRESS}: The user account's mail address.
  • ${FIDO_IDENTITY_SERVICE}: The name of the Identity Service.
  • ${REGISTRATION_VERIFY_LINK}: The link to JOC Cockpit that is used for confirmation of the user's mail address.
• When sending HTML mails then the Content Type setting in the Connection tab should carry the value text/html. For plain text mails the value accordingly should be text/plain.
Users can toggle between source and preview
• of
the HTML e-mail body.Tab Notification E-Mail: This tab holds
• a
mail template that is used to notify a
• user
about approval of the registration
• .

Image Removed
• • Send Mail to notify successful registration: If the checkbox is checked then related mails will be sent.
  • Subject: The subject of the mail. Users can modify the subject at their will.
  • Body: The body of the mail. Users are free to adjust the mail body.
    • By default an HTML template is provided that holds the following variables that will be substituted when sending mail:
      • ${JOC_URL}: The JOC Cockpit URL.
      • ${JOC_REVERSE_PROXY_URL}: The JOC Cockpit URL that is used if a reverse proxy is in place. The variable makes use of the joc_reverse_proxy_url setting in the JS7 - Settings.
    • When sending HTML mails then the Content Type setting in the Connection tab should carry the value text/html. For plain text mails the value accordingly should be text/plain.
    • Users can toggle between source and preview of the HTML e-mail body.

FIDO Flows

if one or more FIDO Identity Services are configured as a first factor for authentication then this is offered to users from JOC Cockpit's login screen like this:

Image Modified

This suggests the following flow to users:

• Users first have to register their Security Key device.
• Later on users can use the Continue with ...<Identity Service Name> link to authenticate.

Registration by Users

...

• the name of the user account,
• the user's e-mail address.
  • Users can register just once for a given e-mail address and account.
  • Users can register with additional JOC Cockpit instances specifying the same account and e-mail address.
  • Users can add additional Security Key devices devices from their Profile once they are logged in.
    
    

Image Modified

If a JS7 - JOC Cockpit Cluster is operated then registration of Security Keys has to be performed for each JOC Cockpit instance individually.

...

• For example, if Windows® Hello is enabled, optionally for Windows login, then users first might receive a popup window to login using the Windows Authenticator.
  
  Image Modified
  
  
• Users can cancel the popup window if they want to register a Security Key that is not managed by Windows® Hello.

...

At this point in time users should have their Security Key readily available and connected. For example, if a USB stick is used then it should be connected to the computer that runs the browser with access to JOC Cockpit.

Image Modified

A follow-up popup window informs abut the fact that the brand and model of the Security Key will be displayed like this:

Image Modified

In the next step the user is asked to specify the PIN for access to the Security Key. If a PIN, biometric characteristics or other will be requested to access the Security Key depends on the nature of the Authenticator.

• The PIN or other characteristics are configured once during initial operation of a Security Key. The same input is required when the Security Key is used later on.
• If the Security Key is is used for the first time then a dialog is added to specify and to confirm the PIN or other characteristics.
  
  

Image Modified

The next popup window asks the user for a gesture. This will happen

• if the FIDO Identity Service is configured for preferred or required user verification,
• if the user's Security Key is is equipped for use of gestures such as touching a USB stickStick.
  
  

Image Modified

With this step the registration request is completed.

...

The user is sent an e-mail from JOC Cockpit that includes a link to JOC Cockpit which is used to confirm the user's e-mail address like this:

Image Modified

Users should check if the indicated e-mail address corresponds to their address and if the URL offered to confirm their e-mail address starts from the same hostname as the JOC Cockpit URL used for registration. If in doubt users should not follow links in the confirmation mail but get in contact to their JS7 administrator.

Clicking the link will bring up a JOC Cockpit confirmation window. The information that a user did follow the link to confirm the e-mail address is stated with the Identity Service's Pending Requests, see Approval flow.

Image Modified

Adding Security Keys

...

The user's profile page offers the action to add Security Keys like this:

Image Modified

If a user clicks the + icon the then the same registration dialog occurs as explained above.

...

The Accounts sub-view offers the action menu item Add Security Key Device:

Image Modified

When this action menu item is clicked then the same steps occur as for registration by users.

...

The users' registration requests are added to the Identity Service's Pending Requests sub-view like this:

Image Modified

Explanation:

...

To approve a pending request JS7 administrators can use the request's action menu like this:

Image Modified

Explanation:

...

• From the Accounts sub-view the action menu for the respective user account offers a number of actions.
• The Edit action is used to assign roles.
  
  

Image Modified

When selecting the Edit action the following popup window is displayed:

• This allows to assign the user account one or more roles.
• The roles can be managed individually per environment. The below screenshot shows the JS7 - Default Roles and Permissions available with JOC Cockpit.
  
  

Image Modified

For more information about roles and permissions see JS7 - Management of User Accounts, Roles and Permissions.

...

With approval of a user's registration request the user is sent an e-mail from JOC Cockpit that notifies about successful completion of the registration request like this:

Image Modified

Users should check if the indicated e-mail address corresponds to their address and if the URL offered to navigate to JOC Cockpit starts from the same hostname as the JOC Cockpit URL used for registration. If in doubt users should not follow links in the confirmation mail but get in contact to their JS7 administrator.

...

• If Windows® Hello is used as an Authenticator for FIDO Passkeys then this option can be used.
• If a Security Key, for example a USB-Stick, is used then this option has to be selected.
  
  

Image Modified