To integrate Single Sign-On (SSO) functionality for PrivaSphere, utilizing Azure Active Directory (AD) in conjunction with your domain accounts, please follow the steps below. To facilitate a smooth implementation, the Azure AD needs these configurations:

We have created a short video tutorial to help you setting up Azure AD:

https://cloud.privasphere.com/index.php/s/6aSteJTeamqELMp

1.  Endpoints Addition: add the following endpoints to our Azure AD for the necessary SSO calls:

   - https://www.privasphere.com/procAzureAdfsPci459.d?sso=DOMAIN (This is for prod, the assertion is privasphere-prod-sp)

   - https://www-dev.privasphere.com/procAzureAdfsPci459.d?sso=DOMAIN (This is for dev testing, the assertion is privasphere-dev-sp)

   - https://lab.privasphere.com:8443/procAzureAdfsPci459.d?sso=DOMAIN (This is for lab testing, the assertion is privasphere-lab-sp)

    

2. Test Account Creation: We will require a test account with an email suffix "@DOMAIN.tld" such as “privasphere-test@DOMAIN.tld” to conduct our testing procedures (no need to have access to any CLIENT_NAME-internal resources).

 

3. User Attributes Specification: The SAML2 ticket of your test account must include, and not be void of, the following user attributes:

   - Display Name

   - Groups – not necessary, but a nice to have  (see the enrollment concept Document for Onboarding providet to you by Privasphere)

   - Given Name

   - Surname

   - Email Address

   - Name

    

4. Certificate Generation: generate the necessary certificates from the endpoints, adhering to the guidelines provided here: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/tutorial-manage-certificates-for-federated-single-sign-on#auto-generated-certificate-for-gallery-and-non-gallery-applications.

 

5. provide request endpoint for Azure, it would look something like so: https://login.microsoftonline.com/FILL_IN/saml2

 

6. XML Export: Lastly, it would be advantageous if you could export and share with PrivaSphere the XML (SAML) that will be generated upon calling the Azure endpoint. (SAML Tracer Firefox AddIn is helpful here)

    

By default, an account already must exist on PrivaSphere platform to log in using SSO. We offer an option where the account would be created automatically if it doesn’t exist when users log in using your SSO. Let us know if this is something that interests you.

Passwords and security questions

We also offer an option that would allow you to not set the security question and the password (the account would only be usable if you log in using SSO) or not to set just the security question or not to set the password, you can choose. This approach is quite handy as users can then just login using SSO and immediately use PrivaSphere, but this also causes some insecurities:

1. Not having a security question leaves your users vulnerable to social engineering attacks as our customer service will not be able to confirm the identity of the user and some unnecessary account information might shared.
2. Not setting the password can be disadvantageous if for example SSO is down on your side, users won’t be able to log in and work until that is fixed.
   Some of our clients have ordered this feature for the benefit of ease of enrolment, but they had to sign a contract stating that they accept the increased risks and PrivaSphere has reduced control over these actions.
   If you do want no password and/or security questions, please contact us to obtain a waiver to be signed. Alternatively, please tell us with what kind of security question and answer accounts should be pre-configured when enrolled with SSO. The questions and answers should be company internal information that is not easily accessible online and should not be something obvious like Q:“where do you work” A:“X”eGov receiving

identification for eGov reception

For users to read eGov email, users need to be identified (that they are a real person and willing to legally interact electronically (https://www.fedlex.admin.ch/eli/cc/2010/408/de#a8)). At the moment this can be done mainly in 4 ways:

1. users with an already active QES on PrivaSphere can identify themselves on the platform under “My Account” / “eGov Registered” feature.
2. users can log in to PrivaSphere platform using a accredited certificate that must meet one of these requirements. Once the user logs in using this certificate, he will be automatically identified by our platform.
3. users using qualified digital signature, sign document that you can find here confirming their identity and send it to info@privasphere.com. The same can be done with multiple accounts, in the same link you will find a document where you can request multiple PrivaSphere accounts to be linked to the root identifier.
4. users order a code by letter to a Swiss address of their choice (5.- Fr service fee) and send the code from their PrivaSphere Account return that code to info@privasphere.com PrivaSphere, then we check the code and mark that user as identified

As you can imagine, this might be inconvenient for you if there are a lot of people that need to be identified, that’s why we are proposing automatic identification using SSO assertions such that you can manage this all in your Active Directory.

There are two primary implementations of this feature, all of your users are identified and everyone can use eGov emails. Or there are only specific set of people that you want to give this access to. If the latter, we recommend to control access to this account via the “Groups” assertions.

For this feature to be enabled, we would need a signed confirmation that users using your SSO will log in to PrivaSphere using ONLY 2FA (requirement by the regulator) and the user using SSO is legally identified and that waves PrivaSphere’s identification responsibility.

In your saml assertion you would specify:
CHeGovIdentified - bool - True/False – mandatory – specify if the user should be eGov identified or not
CHQESAuthorisation - string (currently mobile number MobileID, but can be what you use to confirm your ID) - mandatory – here you specify how the user will confirm his identity
CHQESIdentDocCountry - string - CH – mandatory – user’s country of origin (two characters as per ISO XXX Standard)
CHeGovSearch - enum : "wildcard" vs. "exact" (eMail) – optional – the email is saved in the federal interoperability LDAP server, where citizens can find your email by knowing just your name(wildcard) or by knowing your exact email(exact)

Here is a tutorial how to create attributes for SAML (Custom saml assertations for existing or new values can be implemented in cooperation with you)

• Look for the "Upload SSO images" section.
• Click on “Choose image/svg...” and choose the desired image or SVG file (ensure it's size is below 50KB). (1. in the image below)
• Click on the "Upload" button. (2. in the image below)
• All such administrative actions are logged in the administrators’ account security log.

We recommend to use a SSO-Button image that relates to your “corporate identity” and/or contains a text with reference to “SSO” or “single-sign-on” or “MFA” (your IDP achieves that security level) or … .

We limit the image size for memory constraints and so that the image would be presentable on all devices:
•    max image height – 75px
•    min image height – 20px
•    max image width – 210px
•    min image width – 20px
•    max image size on disk - 50KB

If you wish to change the existing logo:

Click on "Delete Picture".

Follow the aforementioned steps to upload a new one.

Your logo will be prominently displayed during the SSO login prompt, as well as under My Account > Login-Settings.

If an end-user already has a login and you chose not to overrule pre-existing credentials by your IDP, those users will have to activate the SSO after having signed up to PrivaSphere:

Click on "Choose cert...". (1. in the image below)

Your selected certificate will appear above the upload button, allowing you to review or delete any mistakenly added certificates prior to finalizing the upload. (2. In the image)

Absolutely. When implementing SSO, all uploaded certificates are cross-checked, and the appropriate certificate is utilized to authenticate users.

Once your certificate expires and is no longer used by your IDP, you can easily remove it. Furthermore, you can add a new certificate (prior to it really being used by your IDP) for seamless rollover without necessitating any action from the users.

Rollover certificates in Azure AD: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/tutorial-manage-certificates-for-federated-single-sign-on#customize-the-expiration-date-for-your-federation-certificate-and-roll-it-over-to-a-new-certificate

Please mark expirations also in your calendar because otherwise, one morning, your entire staff may no longer to be able log in ☹.

A dedicated table is present beneath the upload button that provides a comprehensive view of your certificates. This table includes details like the certificate name, its expiration status, validity status, upload date, expiry date(black color means that the certificate is valid for more than 60 days, green – valid more than 30 days but less then 60, yellow – valid for less than 30 days and will expire soon and red – has expired) and an issuer button to gather more insights about the certificate. Additionally, there's an option to delete each certificate as needed.

To retrieve the Azure AD endpoints SAML certificate:

• Sign in to the Azure portal.
• Navigate to Azure Active Directory > Enterprise Applications.
• Select the relevant application.
• In the application’s left-hand pane, go to the "Single sign-on" section.
• Then follow this tutorial: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/tutorial-manage-certificates-for-federated-single-sign-on#auto-generated-certificate-for-gallery-and-non-gallery-applications
• Always ensure to stay updated with Azure documentation, as procedures might evolve over time.