Active Directory Integration with Imageshop

Introduction

This article gives a technical description of how to integrate Imageshop with Active Directory.

Single Sign-On (SSO) with Active Directory (AD) can be set up for Imageshop. The requirement for the integration is an identity providers with WS-FED support, like Microsoft Entra ID, OKTA, ADFS or similar.

If group memberships for the user is forwarded to Imageshop, this can be used to give the user access to specific interfaces based on group membership. Default behavior is that all AD users are given access to the internal and public interface (if such exists), and forwarded to the internal interface when accessing Imageshop through AD, but this can be changed so that AD users will be given access to specific interfaces based on group membership in AD.

A specific domain has to be chosen for the AD integration. Optionally all other domains pointing to this interface can be redirected to the AD domain to force AD sign in for all users accessing this interface. In the examples below, I have used screentek.imageshop.no, but this needs to be replaced by the actual domain agreed upon with Imageshop during the setup process.

If the user already exists during login with Active Directory, the user access will remain the same as it was (no additional access will be given and no access will be removed). This means that if an Imageshop Administrator changes the access or blocks a user in Imageshop, the user will be granted / denied access accordingly.

See below for a detailed description of how to integrate with Microsoft Entra ID (option 1) and how to integrate with ADFS (option 2). The same principles will apply when integrating with other providers.

Option 1: Microsoft Entra ID setup

Imageshop has to be added with correct url in the format *.imageshop.<no|dk|se|org>. Usually <organization>ansatt.imageshop.no, <organization>sso.imageshop.org or similar is used, but this must be agreed upon. 

Imageshop needs the following to set up the integration:

• The link to the metadata file
• Application ID of the application
• If the organization uses Office integrations, the ID of the group which will have access. This is needed even though group based access is not used.
• If group based access is used, the ID of all groups along with the name for all groups are needed.

In this example we are using sceentek.imageshop.no as AD url. Use the domain agreed upon with Imageshop. Go to Entra ID in Azure and create a new registration for your domain. Use the domain agreed upon for in the "redirect URI" field.

See below for further settings. Replace all occurrences of  screentek.imageshop.no in the screenshots below with your own domain for connecting with Imageshop provided by us.

Enter the application ID url here.

Option 2: Integration with ADFS or other identity providers with WS-FED support

• Preferably public certificates should be used for token signing, token decryption and service communication if Imageshop should be able to verify the certificate. Otherwise we will have to run without certificate validation or install the root certificate at the Imageshop server.
• Send address of Federationmetadata to Imageshop. Typically it is placed at https://hostname/federationmetadata/2007-06/federationmetadata.xml. Check if it is externally available before sending the address. Otherwise the xml can be sent directly to us (support@imageshop.no).
• We will then send an XML file to you, so you can set up the relying party trust.
• Relying party trust must have the following claims: Note that “Token-Groups” are not mandatory if Imageshop should not to filter access based on this.
  
  

• Set the ADFS server in the intranet zone in Internet Explorer.
• If auto sign on doesn’t work locally, setspn -S http/<adfs server url> <computer name> might fix it depending on which user the AD FS services run as.