Hur konfigureras SSO till Mediaflow plattformen? (gäller inte portaler)
Observera att ni behöver en SSO-licens för att kunna nyttja denna tjänst. Är du osäker om din organisation har det kan du kontakta supporten via mail på support@mediaflow.com.
Det vanligaste förfarandet för våra kunder är att använda SSO mot en Mediaflow Portal. Detta eftersom portalen, till skillnad från själva Mediaflow, har ett förenklat gränssnitt där många användare kan få tillgång till utvalda filer från huvudsystemet, till exempel som en intern mediabank för samtliga anställda. Läs mer om det här
Innehåll
Instruktioner för lokalt AD (ADFS)
Generellt om SSO
Genom att använda SSO kan användarna 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.
Definitioner av begrepp
SSO: 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)
Skillnaden mellan begreppen "Mediaflow" och "Portal"
Det kan vara bra att förstå skillnaden mellan dessa ord, 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.
Portalen däremot är bara en webbplats, oftat under domännamnet mediaflowportal.com, som fungerar som en förlängning av Mediaflow. Det är en plats där administratörerna i Mediaflow kan tillgängliggöra material som resten av organisationen, alternativt helt öppet för omvärlden, behöver kunna ta del av. Från denna plats 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 portalen.
Teknisk information om SSO till Mediaflow
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 sker alltid hos kunden oavsett om inloggning sker mot portal eller Mediaflow-kontot.
Vi behöver kunna se vilken användare det är med hjälp av userPrincipalName. Hur det skickas till oss är upp till hur er IdP fungerar. Azure t.ex. skickar detta med name eller nameidentifier.
SSO till Mediaflow kräver att ni skickar med följande claims/attribut (för SAMl2):
- 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)
Ni får en unik inloggnings-URL av oss som användarna går till för att logga in i Mediaflow. Genom den skickas de först till er AD-inloggning för autentisering. När de har autentiserats skickas de tillbaka till Mediaflow där vi kontrollerar biljetten för att säkerställa att informationen i den stämmer överens med vad vi kommit överens om.
OpenID Connect (OIDC)
Om ni vill använda OpenID Connect (IODC) så är vår Redirect URL: https://api.mediaflow.com/1/oauth2/verify
Ni behöver också skicka med en Discovery URL per klient
Instruktioner
1. Hämta vår metadata från länken nedan
https://sso.mediaflowpro.com/metadata.xml
2. Skapa en SAML2-leverantör i er IdP
Detta gör ni med vår metadata, här kan ni lägga in de claims vi nämnde ovan.
3. Premisser för grundläggande åtkomst (måste bestämmas av er)
Detta går att göra på några olika sätt, men det vanligaste är att ni skapar en eller flera AD-grupper som ska ha åtkomst till Mediaflow och automatiskt få en ny användare när de går genom den nya inloggningslänken första gången.
4. Skicka över er federationsmetadata till oss
När ovan steg är ordnade kan ni skicka över er federationsmetadata till oss och ange vilken/vilka grupper vi ska släppa in.
Om ni använder Azure AD behöver vi ha det som kallas för Object-ID för grupperna. I annat fall ska det gå bra med namnet på gruppen.
Eftersom detta gäller inloggning till Mediaflow, behöver ni tänka på hur många ni ska släppa in. Hur många användare ni får lov att skapa framgår av ert avtal. Det vanliga är att ni har en till några stycken Pro-användare (administratörer), samt ett gäng Basic-användare (standardavtalet brukar tillåta er att registrera upp till 50st Basic-användare utan extra kostnad). Men detta varierar beroende på hur ni satt upp avtalet med oss. Av den anledningen behöver detta kontrolleras på er sida så att detta inte överskrids. Ni kan läsa mer om skillnader mellan Basic, Pro och Pro+admin här
Är ni osäkra på hur många ni får släppa in kan ni höra av er till support@mediaflow.com
5. Vi skapar en unik inloggnings-URL
Vi skapar sedan en unik inloggnings-URL åt er som ni kommer använda för att komma in i Mediaflow framöver. Om en ny användare går genom den länken kommer en ny användare att skapas i Mediaflow, förutsatt att kriterierna uppfylls:
- Att användaren kommer från er och tillhör en grupp i ert AD som har tillåtelse att använda applikationen.
- Att gruppen i ert AD har registrerats hos oss (ni skickar namn eller object-ID för gruppen till oss) som den grupp/en av de grupper som ska få tillgång till Mediaflow.
- Att användaren inte finns i Mediaflow sedan tidigare (då kommer användaren bara att loggas in).
6. Koppla grupper (inget måste, men kan underlätta för er)
När Mediaflow-kontot skapades av oss så skapades det med en grupp som heter "Alla användare". Ni kan inte påverka vilka användare som ska ingå i den gruppen, den finns för att administratörerna ska kunna ge grundläggande behörigheter så som att kunna logga in, ladda ner och indexera filer osv. Utöver den kan administratörerna skapa fler grupper för att tilldela speciella rättigheter beroende på vad användaren ska kunna göra. Oftast skapar man också en grupp som heter "Administratörer" där man lägger in de som är/ska vara Pro+admin som ska kunna administrera de olika funktionerna.
Då kan det vara smidigt för er att vi "mappar" grupper mellan ert AD och Mediaflow.
Att "mappa grupper" innebär att vi skapar en relation mellan en utvald grupp i ert AD och en grupp i Mediaflow, så när användaren första gången går genom er inloggningslänk och får en egen användare så läggs den också till i gruppen i Mediaflow.
Bestäm detta internt, sedan skickar ni över gruppens namn/object-ID och berätta för oss vilken grupp i Mediaflow ni vill koppla ihop med den.
7. Ni kan välja vilka användartyper som ska tilldelas (inget måste, men kan underlätta för er)
Vi kan också sätta upp regler för vilken typ av användare man ska få. Det vanliga är att vi sätter Basic som default, och att ni specificerar en grupp hos er som ska få Pro, och en som ska få Pro+admin.
Det går som sagt att skippa detta steg, då kommer alla användare i Mediaflow få en Basic-användare till att börja med, sedan kan administratörerna manuellt byta användartyp i Mediaflow.
Länkar till guidning i gränssnittet för hur det kan sättas upp i olika miljöer
Begränsningar med SSO för Mediaflow
Det går 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 i dagsläget då 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.
Att lägga till en ny användare i Mediaflow kan en administratör göra i gränssnittet. Läs mer om detta här
Det går inte att radera användare i Mediaflow genom AD:et
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. De kommer dock inte kunna logga in i Mediaflow eftersom att enda sättet att logga in är genom er egna inloggnings-URL, som går genom ert AD. Tekniskt sett blir användaren inte tilldelad något lösenord om den skapas automatiskt via er inloggnings-URL. Därför kan användaren inte längre komma in i Mediaflow om den är borttagen från ert AD.
Att ta bort en användare i Mediaflow är enkelt för en administratör att göra i gränssnittet. Läs mer om detta här
Automatisk inhämtning av federationmetadata
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 kunderna 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.
Om ni har 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).
Steg för steg guide, skapa ny applikation och konfigurera SSO i Entra ID (tidigare Azure AD)
Skapa en ny applikation genom att gå in på "Enterprise applications"
sedan på "New application"
sedan på "Create your own application"
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:
Nu är det dags att konfigurera SSO. Klicka på "Single sign-on"
Välj "SAML"
Ladda upp vår metadata som du hittar här: https://sso.mediaflowpro.com/metadata.xml
genom att klicka på "Upload metadata file"
Klicka nu på "Edit" under Attributes & Claims 
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.
- 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
Om ni har lokalt AD (ADFS)
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.
Lokalt AD
Steg 1
Steg 2
Steg 3
Steg 4
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);