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 supporten så få ni hjälp vidare.
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, 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)
Sätta upp inloggning med SSO
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 en Mediaportal eller ett Mediaflowkonto. För att era användare ska kunna logga in i Mediaflow behöver vi kunna se vem det är med hjälp av userPrincipalName (upn). Hur det skickas till oss är upp till hur er IdP fungerar. Azure t.ex. skickar detta med name eller nameidentifier. För åtkomst till en Mediaportal behövs inte detta eftersom ni då inte behöver skapa användare.
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. Om ni endast ska ha SSO för en mediaportal, följ steg 1-3. Om ni ska konfigurera SSO mot Mediaflow, eller både för Mediaflow och en portal, behöver ni följa alla steg i denna guide.
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. 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.
Stegen nedan behöver endast utföras om ni ska konfigurera SSO mot Mediaflow.
4. 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.
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.
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.
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.
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.
Konfigurering
Det finns två varianter av konfigurering av AD/SSO, Entra ID (tidigare Azure AD) eller om ni har Lokalt AD (ADFS).
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".
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.
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.
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);