Hoppa till huvudinnehållet
English (GB)

Inloggning med SSO

Uppdaterad

Genom att använda SSO kan användare logga in på flera applikationer och tjänster med samma användaruppgifter, vilket minskar behovet av att komma ihåg olika lösenord och användarnamn. Detta kan förbättra användarupplevelsen och spara tid för både användare och IT-avdelningar. 

Det medför även ökad säkerhet då det minskar risken för användandet av svaga lösenord, istället används autentiseringstekniker som SAML2 och OpenID Connect. För en IT-avdelning blir det lättare att administrera användaråtkomst till flera applikationer och tjänster, då användarkonton och lösenord till varje applikation hanteras centralt. Då får man dessutom en bättre överblick och kontroll över vilka användare som har tillgång till vilka applikationer och tjänster.

 

Licens för SSO

Om ni önskar att nyttja denna tjänst för Mediaflow behöver ni en SSO-licens. Kontakta er förvaltare eller support@mediaflow.com så hjälper dem er vidare

 

Innehåll

 

SSO för Mediaflow och Mediaportal

Det är viktigt att vara medveten om skillnaden mellan dessa lösningar gällande SSO, då de fungerar på olika sätt och kräver olika mycket arbete.

Mediaflow är gränssnittet för administratörerna varifrån allt styrs. Inne i Mediaflow laddar man upp, indexerar, sorterar, tillgänglighetsanpassar, GDPR- och licens-säkrar sitt material. Här inne finns användarna och grupperna, där användarna påverkas av rättigheterna satta på gruppnivå av administratörerna. Det är användarna inne i Mediaflow som kan "dela ut" material till t.ex. Portalen och integrationerna. Oftast är det bara ett fåtal användare här inne, men ibland finns det anledning att lägga till fler.

Mediaportal däremot är bara en webbplats, oftast under domännamnet mediaflowportal.com eller mediaflow.site, som fungerar som en förlängning av Mediaflow. Det är en plats där administratörerna i Mediaflow kan tillgängliggöra material, till exempel internt för hela er organisationen eller alternativt helt öppet mot press och samarbetspartners. I en Mediaportal kan man bara se och ladda ner material, det går inte att påverka materialet härifrån. Det går inte heller att ladda upp material i en portal.

 

Definitioner av begrepp i artikeln

SSO: Här förklaras begrepp gällande installation av SSO som nämns i artikeln.står för Single Sign-On, vilket innebär att användare kan logga in på flera applikationer eller tjänster med samma användaruppgifter utan att behöva logga in på varje tjänst separat. Till exempel, om du har ett Google-konto kan du använda det för att logga in på Gmail, Google Drive och andra Google-tjänster.

SAML2: Security Assertion Markup Language (SAML) är ett protokoll som används för att utbyta autentiserings- och auktoriseringsuppgifter mellan säkra domäner. SAML2 är den senaste versionen av SAML-protokollet och används ofta för att möjliggöra SSO i företagsmiljöer. Till exempel kan en företagsanvändare logga in på sin företagswebbplats och sedan få tillgång till olika applikationer som man har behörighet till utan att behöva logga in på varje applikation separat.

OpenID Connect: OpenID Connect är ett annat autentiseringsprotokoll som istället bygger på OAuth2-protokollet och används för att autentisera användare i webbapplikationer. Till exempel kan en användare logga in på en e-handelswebbplats med hjälp av sitt Facebook-konto genom att använda OpenID Connect-protokollet.

AD: Active Directory, Microsofts användarhanteringstjänst för Windows-miljöer

Claims: Informationsbitar som innehåller användarattribut eller annan användarinformation, kallas även för attribut, som skickas från IdP:n till SP:n.

Biljett/ticket: Biljetten består av de claims/attribut ni valt att skicka med. Det är biljetten vi tittar på för att avgöra om vi ska släppa in användaren.

Federationmetadata: XML-dokument som innehåller information om hur man kan autentisera mot en given tjänst. Används av SAMl2.

IdP: Identity Provider, tjänsten som autentiserar användaren och utfärdar en säkerhetsbiljett (kundsidan)

SP: Service Provider, tjänsten som använder säkerhetsbiljetten för att autentisera användaren till dess tjänster (Mediaflow i detta fall)

 

Teknisk översikt

För att använda SSO med våra tjänster behöver ni ha en Identity provider (IdP) som stödjer antingen SAML2 eller OpenID Connect. Autentiseringen sköts alltid av kundens IdP, oavsett om inloggning sker mot en Mediaportal eller ett Mediaflowkonto. Efter autentisering sker en hand-off till vårt interna OAuth 2.0-flöde.

 

Flöde för autentisering

Vår plattform använder ett frånkopplat flöde som kan hantera SAML 2.0 och OpenID Connect (OIDC). Principen är densamma oavsett protokoll:

  1. En extern, betrodd Identity Provider (IdP) verifierar användarens identitet.
  2. Den verifierade identiteten lämnas över till vår interna OAuth 2.0-tjänst.

  3. Vår tjänst utfärdar ett internt Access Token som används för all kommunikation med vårt API.

     

  • Initiering av flöde
    • Flödet initieras när en oautentiserad användare anropar en skyddad resurs på en av Mediaflows domäner. Beroende på konfigurationen för er organisation startas antingen ett SAML- eller OIDC-flöde.
  • Identitetsverifiering (Här skiljer sig processen åt beroende på valt protokoll)
    • Autentisering via SAML 2.0
      • SAML AuthnRequest: Vår Service Provider (SP) genererar en SAMLRequest och omdirigerar användaren till er IdP.
      • Användarautentisering: Användaren loggar in hos er IdP med sina organisationsuppgifter.
      • SAML Response: Er IdP skapar en signerad SAML Response som innehåller en SAML Assertion med användarens attribut (claims).
      • POST till SP:s ACS: Användaren omdirigeras tillbaka till vår Assertion Consumer Service (ACS) med sin SAML Response.
      • Validering: Vi validerar signaturen, utfärdaren (Issuer), mottagaren (Audience) och tidsstämplar i SAML Response och extraherar användarens attribut.
    • Autentisering via OpenID Connect (OIDC)
      • Authentication Request: Vår klient (Relying Party) omdirigerar användaren till er IdP:s /authorize-endpoint enligt Authorization Code Flow.
      • Användarautentisering & Consent: Användaren loggar in hos er IdP och godkänner (vid behov) de scopes som efterfrågas.
      • Authorization Code: Er IdP omdirigerar användaren tillbaka till vår redirect_uri med en authorization_code.
      • Token Exchange: Vår backend gör ett back-channel-anrop till er IdP:s /token-endpoint och byter authorization_code mot ett ID Token och ett access_token.
      • Hämta användarattribut via UserInfo: Istället för att extrahera attributen (claims) direkt från ID Token, använder vår backend det access_token som precis erhölls för att göra ett säkert server-till-server-anrop till IdP:ns userinfo_endpoint. Denna endpoint, vars adress vi hittar via er Discovery URL, returnerar all nödvändig användarinformation (namn, e-post, grupper etc.).
  • Hand-off till internt OAuth 2.0-flöde
    • Här förenas flödena. Oavsett om identiteten verifierades via en SAML Assertion eller om attributen hämtades från en OIDC UserInfo Endpoint, är resultatet detsamma: en säkerställd identitet med en uppsättning attribut.
    • Denna verifierade identitet lämnas nu över till vår centrala accounts-service. Tjänsten identifierar eller provisionerar användaren i Mediaflows databas baserat på de inkommande attributen.
  • Utfärdande av Mediaflow Access Token
    • Vår accounts-service genererar ett kortlivat, signerat JWT (JSON Web Token) som fungerar som ett access_token enligt OAuth 2.0-standarden. Detta token returneras till användarens klient.

  • API-kommunikation med Bearer Token

    • För alla efterföljande anrop till Mediaflows API måste klienten inkludera sitt access_token i Authorization-headern som ett Bearer Token:
    • Authorization: Bearer <access_token>
    • API:et validerar detta JWT vid varje anrop för att auktorisera requesten.

 

Claims/Scopes

SAML 2.0 Claims/Attribut

Vi förväntar oss dessa claims i SAML-flödet:

  • 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

Vi förväntar oss dessa scopes i OIDC-flödet:

  • openid (obligatoriskt)
  • profile
  • email
  • groups

 

Appregistrering/Lägg till Relying Party Trust

SAML 2.0

  • Hämta vår metadata

  • Lägg till en förlitande part (Relying Party Trust) i er IdP

    • Detta gör ni med vår federationsmetadata. Därefter kan ni lägga in de claims vi nämnde ovan.

  • Skicka federationsmetadata till oss

    • Federationsmetadata

    • Grupper för åtkomst och mappning

OpenID Connect (OIDC)

  • Hämta vår redirect-URI
    • Redirect-URI: https://api.mediaflow.com/1/oauth2/verify
  • Gör en Appregistrering i er IdP
    • Namnge appen
    • Lägg in vår redirect-URI
    • Skapa client secret
    • Definiera scopes
  • Skicka över följande:
    • Discovery-URL
    • Client ID
    • Client secret
    • Vilka era definierade scopes är

 

Hur ni styr åtkomst till Mediaflows admindel

Flödet mellan portal och admindelen av Mediaflow skiljer sig. För åtkomst till portalen skickas autentiseringsförfrågan till er IdP och om IdP släpper förbi användaren så släpper vi in användaren i portalen utan att registrera några uppgifter. Provisionering, matchning och mappning av användare i admindelen kräver att ni går igenom nedan steg

 

För att styra vem som kan logga in och vad de får göra i adminverktyget använder vi era AD-grupper. Det finns tre nivåer av integration – där den första är obligatorisk och de andra är valfria för att ytterligare automatisera er användarhantering.

 

Nivå 1: Välj strategi för grundläggande åtkomst (Obligatoriskt val)

För att en användare ska kunna logga in i Mediaflow krävs medlemskap i en godkänd AD-grupp. Här finns två vanliga metoder.

Alternativ A: En samlad åtkomstgrupp (Rekommenderad metod) Ni skapar en specifik AD-grupp, t.ex. AD-grupp-Mediaflow-Access, som enbart hanterar vilka som överhuvudtaget får logga in.

  • Hur det funkar: En användare måste vara medlem i denna grupp för att kunna logga in. Andra grupper (t.ex. för administratörer eller redaktörer) används sedan för att tilldela rättigheter inne i Mediaflow.
  • Fördel: Väldigt säker och lätthanterlig. När en person slutar eller inte längre ska ha tillgång, tar ni bara bort dem från en enda grupp för att helt återkalla åtkomsten. Detta är "best practice" för applikationshantering.

Alternativ B: Åtkomst via funktionsgrupper (Enklare start) Medlemskap i någon av de AD-grupper vi mappar (t.ex. AD-grupp-Admins, AD-grupp-Editors) ger automatiskt behörighet att logga in.

  • Hur det funkar: Vi behöver ingen separat åtkomstgrupp. Om en användare finns i en grupp som ger "Pro"-licens, kan den logga in.
  • Fördel: Kräver ingen ny AD-grupp. Ni kan komma igång snabbt med de grupper ni redan har.
  • Nackdel: För att helt återkalla någons åtkomst måste ni säkerställa att personen är borttagen från alla AD-grupper som är kopplade till Mediaflow.

Vår rekommendation är Alternativ A för bästa långsiktiga kontroll, men båda fungerar utmärkt.

 

Nivå 2: Automatisk grupptilldelning (Valfritt)

Om ni vill att användare automatiskt ska hamna i rätt arbetsgrupper inne i Mediaflow (t.ex. "Marknadsavdelningen" eller "Videoteamet") kan vi mappa era AD-grupper mot dessa.

  • Fördel: Ni slipper hantera gruppmedlemskap manuellt i två olika system. Behörigheter till mappar och filer som styrs av grupper blir automatiskt korrekta.

 

Nivå 3: Automatisk tilldelning av användartyp (Valfritt)

Ni kan även använda AD-grupper för att automatiskt styra vilken licensnivå (användartyp) en person ska ha i Mediaflow.

  • Användartyper: Basic, Pro, Pro+Admin.
  • Fördel: Ni får full kontroll över licenskostnader och ser till att rätt personer får rätt verktyg, direkt från ert AD.

Antalet användare styrs av ert avtal

Hur många användare ni kan skapa i Mediaflow styrs av ert avtal. Oftast har man ett begränsat antal Pro-användare (administratörer) och upp till 50 Basic-användare. Kontrollera ert avtal för att säkerställa att ni håller er inom de överenskomna användargränserna. Läs mer om olika typer av användare i Mediaflow här.

 

Återkom till oss med:

Diskutera dessa saker internt: Bestäm vilken nivå av automatisering som passar er. Behöver ni bara grundläggande inloggning (Nivå 1), eller vill ni även automatisera grupper och användartyper (Nivå 2 & 3)?

Återkom till oss:

  • Om ni endast vill ha grundläggande inloggning, meddela oss vilken/vilka AD-grupper som ska ge åtkomst.
  • Om ni vill använda Nivå 2 och/eller 3, skapa en tabell enligt exemplet nedan och skicka tillbaka

Vi finns här för att bolla idéer om ni är osäkra på vilken lösning som är bäst för er.


 

Exempeltabell för mappning

Fyll i de rader som är relevanta för er. Om en AD-grupp bara ska ge inloggning men inte mappas till en specifik Mediaflow-grupp, lämna den kolumnen tom.

Nedan ser ni ett exempel på hur en sådan tabell kan vara uppbyggd

Notera att om ni använder Entra ID i Azure behöver vi Object-ID för AD-grupperna

 

AD-grupp Mediaflow-grupp Användartyp
ad_mf_admins Administratörer Pro+admin
ad_mf_video Videoteamet Pro
ad_mf_redaktorer Redaktörer Pro
ad_mf_gdpr GDPR-teamet Basic
ad_mf_internkommunikation Redaktörer Basic
ad_mf_tempconsultants – Basic
ad_mf_allusers – Basic

 

Inloggningslänken för er organisation

Som ett sista steg i processen skapar vi en unik inloggningslänk för er. Denna länk är framtagen för att vara den enda adress era användare behöver för att komma åt Mediaflow med sina företagskonton.

 

Hur fungerar länken?

Varje gång en person använder länken genomför systemet en smart kontroll för att hantera användaren på rätt sätt:

Först försöker systemet matcha personens unika ID från ert AD (User Principal Name) mot ett befintligt användarnamn i Mediaflow.

  • Om en matchning hittas: Användaren loggas in smidigt på sitt befintliga konto.
  • Om ingen matchning hittas: Systemet skapar automatiskt ett helt nytt konto, förutsatt att personen tillhör en godkänd grupp i ert AD. Detta innebär att nya, behöriga medarbetare får tillgång direkt utan manuell handpåläggning.

Vem får tillgång?

Tillgången styrs alltid av de regler ni har satt upp. En användare ges tillgång om de har loggat in korrekt med sitt företagskonto och tillhör en på förhand bestämd grupp i ert AD som har fått behörighet till Mediaflow.

 

Valfritt steg: Säkerställ att endast SSO-inloggning används

För att maximera säkerheten och garantera att all inloggning till Mediaflow sker via er centrala identitetsleverantör (IdP), rekommenderar vi att inaktivera möjligheten att logga in med traditionellt användarnamn och lösenord. Detta skapar en enda, kontrollerad väg in i systemet för alla era användare.

Detta är ett sista steg som vi utför på er begäran efter att SSO-flödet har verifierats.

 

Processen för att tvinga SSO-inloggning:

När ni ger oss klartecken, hanterar vi följande två åtgärder i vårt system:

  1. Borttagning av befintliga lösenord: För användare som skapades innan SSO aktiverades tar vi bort deras lagrade lösenord. Detta gör det omöjligt att logga in med gamla uppgifter.
  2. Inaktivering av "Glömt lösenord": Vi stänger av "Glömt lösenord"-funktionen specifikt för er organisation. Detta förhindrar att användare av misstag kan skapa ett nytt lösenord och kringgå SSO-flödet.

Användarupplevelsen efter ändringen:

Om en användare ändå skulle försöka återställa sitt lösenord, kommer de antingen att mötas av ett meddelande direkt på sidan som informerar om att funktionen är inaktiverad, eller motta ett e-postmeddelande med samma besked. 

Viktigt: Denna åtgärd utförs först när ni har testat och bekräftat för oss att inloggning via SSO fungerar som förväntat för era användare. Detta säkerställer en smidig övergång utan att någon riskerar att bli utelåst.

 

Begränsningar

 

Inloggning i Pro-plugins fungerar inte med SSO

Det går i dagsläget inte att logga in i våra plugins för InDesign och Office (för Pro-användare) med SSO. Eftersom dessa applikationer inte går att specialanpassa idag med en egen inloggningssida så är det inte möjlig att logga med SSO i våra plugins för InDesign och Office (för Pro-användare). Det går heller inte att logga in i dessa plugins om man har fått en användare automatiskt eftersom det krävs både ett användarnamn och ett lösenord.

 

Tillfällig lösning för att kombinera SSO med våra plugins för Pro-användare

När en person går genom er unika inloggnings-URL för att komma till ert Mediaflow-konto första gången så skapas en ny användare (förutsatt att personen ingår i ert AD och uppfyller kriterierna vi satt upp med er). Användaren som skapas får inget lösenord, utan autentiseringen sker på er sida. När en användare sedan vill använda t.ex. vårt InDesign-plugin så kommer man mötas av en inloggningsruta som kräver både användarnamn och lösenord. Eftersom att användaren inte fått något lösenord och vi idag inte har möjlighet att logga in er med SSO där, går det inte att komma in. För att komma runt problemet för tillfället så kan administratörerna i Mediaflow skapa en ny användare som specifikt används för att kunna nyttja dessa plugins. Det viktiga är att administratören väljer att göra användaren till en Pro-användare då det bara är den typen av användare som kan logga in i pluginet.

 

Radera användare måste skötas manuellt

Notera att om en användare raderas från ert AD, raderas den inte automatiskt från Mediaflow. Idag finns det inget sätt för oss att veta vilka användare som inte längre finns i ert AD. Det innebär att de kommer finnas kvar i Mediaflow även om de inte finns kvar i ert AD. SAML2 och OIDC bygger på en teknik som förhindrar SP från att ha insyn i ert AD, vilket är en säkerhetsaspekt i flödet. Det innebär att användare kommer finnas kvar i Mediaflow även om de tas bort från ert AD. Trots att användaren tekniskt sett finns kvar i Mediaflow finns det inget sätt att logga in på då inget lösenord har skapats åt användaren.

 

Ingen automatisk inhämtning av metadata

I nuläget har vi inte implementerat stöd för att hämta metadata från en metadata-endpoint. Det innebär att vi förväntar oss att kunder själva tillhandahåller sin federationmetadata i form av en XML-fil som vi läser in på vår server. Om certifikatet i XML-filen går ut behöver ni skicka över den nya filen med nytt certifikat i. Vi undersöker dock möjligheten att implementera denna funktion i framtiden för att underlätta för våra kunder och minska manuellt arbete.

 

Konfigureringsguider för Entra ID och AD FS för SAML 2.0

Nedan guider visar hur man kan lägga till Relying party trust i Entra ID respektive AD FS för SAML 2.0-flödet.

 

Entra ID (tidigare Azure AD)

Ni kan konfigurera applikationen i Azure enligt skärmdumparna nedan. Gruppmedlemskap kan ni skicka antingen som grupper eller som roller (ni har möjlighet att själva styra vilka grupper / typer av grupper som ska skickas över, men nedan skickas bara grupper som är tilldelade/assigned till applikationen).

Skapa en ny applikation genom att gå in på "Enterprise applications".

Enterprise-jpg.webp

 

sedan på "New application".

New_Application-jpg-1.webp

 

sedan på "Create your own application".

Create-jpg.jpg

 

Döp applikationen till något, t.ex. "Mediaflow" som på bilden. Se också till så att radioknappen står på "Integrate any other..." som på bilden:

Create your own-jpg.webp

 

Nu är det dags att konfigurera SSO. Klicka på "Single sign-on".

SSO-jpg.jpg

 

Välj "SAML".

SAML-jpg.jpg

 

Ladda upp vår metadata som du hittar här: https://sso.mediaflowpro.com/metadata.xml genom att klicka på "Upload metadata file".

Ladda upp-jpg.jpg

 

Klicka nu på "Edit" under Attributes & Claims.

Claims-jpg.webp

 

Lägg till claims som det ser ut på bilden, de går att kopiera under bilden också. Tänk på att claim för groups läggs till genom att klicka på "Add a group claim". Förslagsvis kan man använda alternativet "Groups assigned to the application" så skickas inga irrelevanta grupper till oss utan endast de ni vill att vi ska kunna se.

Attributes & Claims-jpg.jpg

  • emailadress (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)

 

Ladda sedan ner er federationsmetadata och skicka över den till oss.

Ladda ner-jpg.webp

 

Lokalt AD (AD FS)

När ni sätter upp claims/attribut för gruppmedlemskap kan ni skicka antingen som grupper eller som roller (ni väljer själva vilka grupper / typer av grupper som ska skickas över) Så här ser det ut i Azure ADFS.

Steg 1

Steg1.png

 

Steg 2

Steg2.png

 

Steg 3

Steg3.png

Steg 4

Steg5.png


I Custom Rule anger ni texten:

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);

Relaterade artiklar