Microsoft Azure SSO implementation steps

Only CDD version 4.14 and Outlook Plugin version 2.9 and newer versions support Azure SSO - those versions are not yet publicly distributed (April 2024)

In these example we will use the following data which will be different in your case and needs to be adjusted according to domain name provided for you:

CoreData portal address (use address provided for your organization)

CODE

https://test01-dev.coredata.is

Configuration steps needed on Microsoft Azure

Create new Enterprise Application:
Go to Single sign-on:
Setup Basic SAML Configuration:
Please pay ATTENTION to the slash symbol at the end - it’s important: “/”.
Setup Attributes & Claims:

user.groups custom claim setting with more details
In SAML Certificates download the metadata XML. It Contains Azure public certificates. Remember that from time to time they expire. In case of any issues with SSO - please try donwloading new version from Azure and re-upload to CoreData as shown later in this guide:
Copy the marked Login URL and Logout URL and provide it also for CoreData support:
Almost done! Now you need to create if needed a new Azure Active Directory group of users who should be allowed to use CoreData. Or you can re-use existing Group. You need to provide the group Object ID for CoreData support.

Configuration steps needed on CoreData

Continue with these steps as one of CoreData support roles: admin_delegate or administrator when configuration is ready on Microsoft Azure. Make sure you have collected these details from Microsoft Azure cloud admin dashboard:

Login URL.
Logout URL.
Federation Metadata XML file.
Group Object ID.

Login to CoreData admin Dashboard as admin_delegate or administrator user:
Go to Security - Identification Providers
Tip: if you do not see this tab - please contact CoreData support so that SSO extension would be enabled for you.
Fill in Group Object ID (Can be found on step with Azure Active Directory):
Entity ID:
Just need to put correct domain name, the remaining part of URL is the same for all deployments.

Example:
Please pay ATTENTION to the slash symbol at the end - it’s important: “/”.
CODE
```
https://test01-dev.coredata.is/saml2/metadata/
```

Identity Provider Login URL

Example:

CODE

https://login.microsoftonline.com/e29c653a-0202-43cf-976a-8b0242fe7c14/saml2

Identity Provider Logout URL

Example:

CODE

https://login.microsoftonline.com/e29c653a-0202-43cf-976a-8b0242fe7c14/saml2

Upload metadata XML from Azure:
If you are configuring an IDP which does not provide a public federation metadata URL, then you may want to upload up to date federation metadata manually:
Enable the option provided below:
Message encryption:
Enable SAML response signature requirement:
Here you can put a private and public key certificates generated using OpenSSL. These certificates can be self-signed. Or they can be issued by certificate authority. Here we will provide steps for Self-Signed.

Generate private key:
CODE
```
openssl genrsa -out private.key 4096
```
Generate public key (in this example certificate will work for 2 years, remember to update because otherwise SSO functionality will stop working):
CODE
```
# Variables to set:
CORE_DOMAIN="" # change this to domain which was assigned for you
CORE_EMAIL="devops@coredata.is" # can change if needed
# Command:
openssl req -x509 -new -nodes -days 730 -key private.key -sha256 -out public.pem -subj "/C=IS/ST=Lagmuli/L=Reykjavik/O=Coredata Solutions ehf./CN=$CORE_DOMAIN/emailAddress=$CORE_EMAIL"
```
Upload the files.
Finished. You cant test the integration by directly logging in to CoreData or by clicking from Azure Dashboard:

That should take you to CoreData.

Azure AD certificate expiration

When current certificate expires in Azure AD:

Azure AD does not create a new certificate automatically.
Azure AD does not activate the next certificate automatically.

Usually certificates expire every 2 years.

Azure AD certificate renewal

Having the information provided above here is a scenario example of how to approach an expiring Azure AD certificate renewal:

Given:
1. An active Azure AD certificate expiring soon.
2. CoreData has an up-to-date metadata XML file uploaded earlier.
3. CoreData SSO is configured for the given Azure AD and working properly.
System Administrator:
1. Receives a notification regarding the expiring certificate from Azure AD.
2. Creates a new inactive certificate in Azure AD. The new certificate validity period overlaps with the currently active certificate.
3. Downloads the latest federation metadata XML from Azure AD and uploads it to CoreData.
When current Azure AD certificate is about to expire (or any time earlier, after creating a new certificate) System Administrator activates the new certificate and deletes the old one.
CoreData SSO continues working as CoreData already has a metadata file containing the newly activated certificate.

Troubleshooting

Problems usually occurs when Azure SSO certificates expire.

Error 400: Outdated federation metadata file

New metadata file needs to be fetched from Azure (soon this will be automatic). If federation metadata file is outdated - user should see the following page during SSO login:

Coredata logs will contain similar log entries containing keywords:

CODE

signature does not verify

If you still experience the same issue - please review the TLS certificates on Microsoft Azure side and on CoreData.

Error 403

This error can be triggered by following route causes:

corresponding CoreData user is missing or deactivated
Identity Provider config Required group does not match any of the Azure AD groups of the signing in user.

Error 500: A server error occured

CODE

signature does not verify
Error: failed to verify file "/tmp/tmpxxxxxxxxx.xml"

From our experience this issue was solved by fetching new federation.xml file.