Skip to main content
Svenska

Login with SSO

Updated

By using SSO, users can log in to multiple applications and services with the same credentials, reducing the need to remember different passwords and usernames. This can improve the user experience and save time for both users and IT departments. 

It also increases security as it reduces the risk of using weak passwords; instead, authentication technologies such as SAML2 and OpenID Connect are used. For an IT department, it becomes easier to manage user access to multiple applications and services since user accounts and passwords for each application are managed centrally. Additionally, you gain better oversight and control over which users have access to which applications and services.

 

License for SSO

If you wish to use this service for Mediaflow, you need an SSO license. Contact your administrator or support@mediaflow.com and they will assist you further.

 

Contents

 

SSO for Mediaflow and Media Portal

It is important to be aware of the difference between these solutions regarding SSO, as they work differently and require different amounts of work.

Mediaflow is the interface for administrators from where everything is controlled. Inside Mediaflow, you upload, index, sort, make your material accessible, and ensure GDPR and license compliance. Here are the users and groups, where the users are affected by the rights set at group level by the administrators. It is the users inside Mediaflow who can "distribute" material to, for example, the Portal and integrations. Usually, there are only a few users here, but sometimes there is a reason to add more.

Media Portal, on the other hand, is just a website, usually under the domain name mediaflowportal.com or mediaflow.site, which acts as an extension of Mediaflow. It is a place where administrators in Mediaflow can make material available, for example internally for your entire organisation or alternatively completely open to the press and partners. In a Media Portal, you can only view and download material; it is not possible to modify the material from here. It is also not possible to upload material to a portal.

 

Definitions of terms in the article

SSO: Here the terms related to the installation of SSO mentioned in the article are explained. Stands for Single Sign-On, which means that users can log in to multiple applications or services with the same credentials without having to log in to each service separately. For example, if you have a Google account, you can use it to log in to Gmail, Google Drive, and other Google services.

SAML2: Security Assertion Markup Language (SAML) is a protocol used to exchange authentication and authorization data between secure domains. SAML2 is the latest version of the SAML protocol and is often used to enable SSO in corporate environments. For example, a corporate user can log in to their corporate website and then access various applications they are authorised for without logging in separately to each application.

OpenID Connect: OpenID Connect is another authentication protocol that is instead based on the OAuth2 protocol and is used to authenticate users in web applications. For example, a user can log in to an e-commerce website using their Facebook account by using the OpenID Connect protocol.

AD: Active Directory, Microsoft's user management service for Windows environments

Claims: Pieces of information containing user attributes or other user information, also called attributes, which are sent from the IdP to the SP.

Ticket: The ticket consists of the claims/attributes you have chosen to send. It is the ticket we look at to decide whether to allow the user in.

Federation metadata: XML document containing information on how to authenticate against a given service. Used by SAML2.

IdP: Identity Provider, the service that authenticates the user and issues a security ticket (customer side)

SP: Service Provider, the service that uses the security ticket to authenticate the user to its services (Mediaflow in this case)

 

Technical overview

To use SSO with our services, you need an Identity Provider (IdP) that supports either SAML2 or OpenID Connect. Authentication is always handled by the customer's IdP, whether logging in to a Media Portal or a Mediaflow account. After authentication, a hand-off occurs to our internal OAuth 2.0 flow.

 

Authentication flow

Our platform uses a decoupled flow that can handle SAML 2.0 and OpenID Connect (OIDC). The principle is the same regardless of protocol:

  1. An external, trusted Identity Provider (IdP) verifies the user's identity.
  2. The verified identity is handed over to our internal OAuth 2.0 service.

  3. Our service issues an internal Access Token used for all communication with our API.

     

  • Initiation of flow
    • The flow is initiated when an unauthenticated user requests a protected resource on one of Mediaflow's domains. Depending on your organisation's configuration, either a SAML or OIDC flow is started.
  • Identity verification (Here, the process differs depending on the chosen protocol)
    • Authentication via SAML 2.0
      • SAML AuthnRequest: Our Service Provider (SP) generates a SAMLRequest and redirects the user to your IdP.
      • User authentication: The user logs in at your IdP with their organisational credentials.
      • SAML Response: Your IdP creates a signed SAML Response containing a SAML Assertion with the user's attributes (claims).
      • POST to SP's ACS: The user is redirected back to our Assertion Consumer Service (ACS) with their SAML Response.
      • Validation: We validate the signature, issuer (Issuer), recipient (Audience), and timestamps in the SAML Response and extract the user's attributes.
    • Authentication via OpenID Connect (OIDC)
      • Authentication Request: Our client (Relying Party) redirects the user to your IdP's /authorize endpoint according to the Authorization Code Flow.
      • User Authentication & Consent: The user logs in at your IdP and approves (if necessary) the requested scopes.
      • Authorization Code: Your IdP redirects the user back to our redirect_uri with an authorization_code.
      • Token Exchange: Our backend makes a back-channel call to your IdP's /token endpoint and exchanges the authorization_code for an ID Token and an access_token.
      • Fetch user attributes via UserInfo: Instead of extracting the attributes (claims) directly from the ID Token, our backend uses the newly obtained access_token to make a secure server-to-server call to the IdP's userinfo_endpoint. This endpoint, whose address we find via your Discovery URL, returns all the necessary user information (name, email, groups, etc.).
  • Hand-off to internal OAuth 2.0 flow
    • Here, the flows converge. Regardless of whether the identity was verified via a SAML Assertion or if the attributes were fetched from an OIDC UserInfo Endpoint, the result is the same: a verified identity with a set of attributes.
    • This verified identity is now handed over to our central accounts-service. The service identifies or provisions the user in Mediaflow's database based on the incoming attributes.
  • Issuance of Mediaflow Access Token Our accounts-service generates a short-lived, signed JWT (JSON Web Token) that functions as an access_token according to the OAuth 2.0 standard. This token is returned to the user's client.
  • API Communication with Bearer Token
    • For all subsequent calls to the Mediaflow API, the client must include its access_token in the Authorization header as a Bearer Token:
    • Authorization: Bearer <access_token>
    • The API validates this JWT on every call to authorize the request.

 

Claims/Scopes

SAML 2.0 Claims/Attributes

We expect these claims in the SAML flow:

  • emailaddress (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress)
  • givenname (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname)
  • name (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name)
  • nameidentifier (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier)
  • surname (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname)
  • groups (http://schemas.microsoft.com/ws/2008/06/identity/claims/groups)

OpenID Connect (OIDC) Scopes

We expect these scopes in the OIDC flow:

  • openid (mandatory)
  • profile
  • email
  • groups

 

App registration/Add Relying Party Trust

SAML 2.0

  • Download our metadata

  • Add a relying party trust in your IdP

    • You do this with our federation metadata. After that, you can add the claims we mentioned above.

  • Send federation metadata to us

    • Federation metadata

    • Groups for access and mapping

OpenID Connect (OIDC)

  • Get our redirect URI
    • Redirect URI: https://api.mediaflow.com/1/oauth2/verify
  • Register an app in your IdP
    • Name the app
    • Add our redirect URI
    • Create client secret
    • Define scopes
  • Send the following:
    • Discovery URL
    • Client ID
    • Client secret
    • Which scopes you have defined

 

How you control access to Mediaflow's admin area

The flow between the portal and the admin area of Mediaflow differs. For access to the portal, the authentication request is sent to your IdP, and if the IdP allows the user through, we allow the user into the portal without recording any information. Provisioning, matching, and mapping of users in the admin area requires you to follow the steps below.

 

To control who can log in and what they can do in the admin tool, we use your AD groups. There are three levels of integration – where the first is mandatory and the others are optional to further automate your user management.

 

Level 1: Choose a strategy for basic access (Mandatory choice)

For a user to be able to log in to Mediaflow, membership in an approved AD group is required. There are two common methods here.

Option A: A consolidated access group (Recommended method) You create a specific AD group, e.g. AD-group-Mediaflow-Access, which only manages who is allowed to log in at all.

  • How it works: A user must be a member of this group to be able to log in. Other groups (e.g. for administrators or editors) are then used to assign rights inside Mediaflow.
  • Advantage: Very secure and easy to manage. When a person leaves or should no longer have access, you just remove them from one single group to fully revoke access. This is "best practice" for application management.

Option B: Access via functional groups (Easier start) Membership in any of the AD groups we map (e.g. AD-group-Admins, AD-group-Editors) automatically grants permission to log in.

  • How it works: We do not need a separate access group. If a user is in a group that grants a "Pro" license, they can log in.
  • Advantage: Requires no new AD group. You can get started quickly with the groups you already have.
  • Disadvantage: To fully revoke someone's access, you must ensure that the person is removed from all AD groups linked to Mediaflow.

Our recommendation is Option A for the best long-term control, but both work excellently.

 

Level 2: Automatic group assignment (Optional)

If you want users to automatically be placed in the correct workgroups inside Mediaflow (e.g. "Marketing Department" or "Video Team"), we can map your AD groups to these.

  • Advantage: You avoid managing group membership manually in two different systems. Permissions to folders and files controlled by groups become automatically correct.

 

Level 3: Automatic assignment of user type (Optional)

You can also use AD groups to automatically control which license level (user type) a person should have in Mediaflow.

  • User types: Basic, Pro, Pro+Admin.
  • Advantage: You get full control over license costs and ensure that the right people get the right tools, directly from your AD.

The number of users is governed by your agreement

How many users you can create in Mediaflow is governed by your agreement. Usually, there is a limited number of Pro users (administrators) and up to 50 Basic users. Check your agreement to ensure you stay within the agreed user limits. Read more about different types of users in Mediaflow here.

 

Get back to us with:

Discuss these matters internally: Decide which level of automation suits you. Do you only need basic login (Level 1), or do you also want to automate groups and user types (Levels 2 & 3)?

Get back to us:

  • If you only want basic login, inform us which AD group(s) should grant access.
  • If you want to use Levels 2 and/or 3, create a table according to the example below and send it back.

We are here to discuss ideas if you are unsure which solution is best for you.


 

Example table for mapping

Fill in the rows relevant to you. If an AD group should only grant login but not be mapped to a specific Mediaflow group, leave that column empty.

Below is an example of how such a table can be structured.

Note that if you use Entra ID in Azure, we need the Object ID for the AD groups

 

AD group Mediaflow group User type
ad_mf_admins Administrators Pro+admin
ad_mf_video Video Team Pro
ad_mf_editors Editors Pro
ad_mf_gdpr GDPR Team Basic
ad_mf_internal_communication Editors Basic
ad_mf_tempconsultants – Basic
ad_mf_allusers – Basic

 

Login link for your organisation

As a final step in the process, we create a unique login link for you. This link is designed to be the only address your users need to access Mediaflow with their corporate accounts.

 

How does the link work?

Each time a person uses the link, the system performs a smart check to handle the user correctly:

First, the system tries to match the person's unique ID from your AD (User Principal Name) against an existing username in Mediaflow.

  • If a match is found: The user is smoothly logged into their existing account.
  • If no match is found: The system automatically creates a brand new account, provided that the person belongs to an approved group in your AD. This means that new, authorised employees get access immediately without manual intervention.

Who gets access?

Access is always governed by the rules you have set up. A user is granted access if they have logged in correctly with their corporate account and belong to a pre-defined group in your AD that has been granted permission to Mediaflow.

 

Optional step: Ensure that only SSO login is used

To maximise security and guarantee that all login to Mediaflow occurs via your central identity provider (IdP), we recommend disabling the possibility to log in with traditional username and password. This creates a single, controlled entry point for all your users.

This is a final step that we perform at your request after the SSO flow has been verified.

 

Process to enforce SSO login:

When you give us the go-ahead, we handle the following two actions in our system:

  1. Removal of existing passwords: For users created before SSO was activated, we remove their stored passwords. This makes it impossible to log in with old credentials.
  2. Disabling "Forgot password": We disable the "Forgot password" function specifically for your organisation. This prevents users from accidentally creating a new password and bypassing the SSO flow.

User experience after the change:

If a user tries to reset their password anyway, they will either be met with a message directly on the page informing them that the function is disabled, or receive an email with the same message. 

Important: This action is only performed once you have tested and confirmed to us that login via SSO works as expected for your users. This ensures a smooth transition without anyone risking being locked out.

 

Limitations

 

Login in Pro plugins does not work with SSO

Currently, it is not possible to log in to our plugins for InDesign and Office (for Pro users) with SSO. Since these applications cannot currently be customised with their own login page, it is not possible to log in with SSO in our plugins for InDesign and Office (for Pro users). It is also not possible to log in to these plugins if a user has been created automatically, as both a username and password are required.

 

Temporary solution to combine SSO with our plugins for Pro users

When a person goes through your unique login URL to access your Mediaflow account for the first time, a new user is created (provided the person is in your AD and meets the criteria we have set with you). The created user does not receive a password; authentication occurs on your side. When a user then wants to use, for example, our InDesign plugin, they will be met with a login prompt requiring both username and password. Since the user has not received a password and we currently do not have the possibility to log you in with SSO there, it is not possible to get in. To work around the problem for now, administrators in Mediaflow can create a new user specifically used to utilise these plugins. It is important that the administrator chooses to make the user a Pro user, as only that type of user can log in to the plugin.

 

Deleting users must be done manually

Note that if a user is deleted from your AD, they are not automatically deleted from Mediaflow. Currently, there is no way for us to know which users no longer exist in your AD. This means they will remain in Mediaflow even if they are no longer in your AD. SAML2 and OIDC are based on a technology that prevents the SP from having insight into your AD, which is a security aspect of the flow. This means users will remain in Mediaflow even if removed from your AD. Despite the user technically remaining in Mediaflow, there is no way to log in as no password has been created for the user.

 

No automatic retrieval of metadata

Currently, we have not implemented support for retrieving metadata from a metadata endpoint. This means we expect customers to provide their federation metadata in the form of an XML file, which we load on our server. If the certificate in the XML file expires, you need to send us the new file with the new certificate. However, we are exploring the possibility of implementing this feature in the future to facilitate our customers and reduce manual work.

 

Configuration guides for Entra ID and AD FS for SAML 2.0

The guides below show how to add Relying Party Trust in Entra ID and AD FS respectively for the SAML 2.0 flow.

 

Entra ID (formerly Azure AD)

You can configure the application in Azure according to the screenshots below. Group membership can be sent either as groups or as roles (you have the option to control which groups/types of groups are sent over, but below only groups assigned to the application are sent).

Create a new application by going to "Enterprise applications".

Enterprise-jpg.webp

 

then click "New application".

New_Application-jpg-1.webp

 

then click "Create your own application".

Create-jpg.jpg

 

Name the application something, e.g. "Mediaflow" as in the picture. Also, make sure the radio button is set to "Integrate any other..." as in the picture:

Create your own-jpg.webp

 

Now it is time to configure SSO. Click on "Single sign-on".

SSO-jpg.jpg

 

Select "SAML".

SAML-jpg.jpg

 

Upload our metadata which you can find here: https://sso.mediaflowpro.com/metadata.xml by clicking "Upload metadata file".

Ladda upp-jpg.jpg

 

Now click "Edit" under Attributes & Claims.

Claims-jpg.webp

 

Add claims as shown in the image; they can also be copied below the image. Note that the claim for groups is added by clicking "Add a group claim". It is recommended to use the option "Groups assigned to the application" so that no irrelevant groups are sent to us, only those you want us to see.

Attributes & Claims-jpg.jpg

  • emailaddress (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress)

  • givenname (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname)

  • name (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name)

  • nameidentifier (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier)

  • surname (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname)

  • groups (http://schemas.microsoft.com/ws/2008/06/identity/claims/groups)

 

Then download your federation metadata and send it to us.

Ladda ner-jpg.webp

 

Local AD (AD FS)

When setting up claims/attributes for group membership, you can send them either as groups or as roles (you choose which groups/types of groups to send). This is how it looks in Azure ADFS.

Step 1

Steg1.png

 

Step 2

Steg2.png

 

Step 3

Steg3.png

Step 4

Steg5.png


In Custom Rule, enter the text:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname", "http://schemas.microsoft.com/ws/2008/06/identity/claims/groups"), query = ";mail,givenName,userPrincipalName,userPrincipalName,sn,tokenGroups(domainQualifiedName);{0}", param = c.Value);

Was this article helpful?

0 out of 0 found this helpful
Return to top

Related articles