SSO till en Mediaflow Portal

Hur konfigureras SSO till Mediaflows 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 på support@mediaflow.com

Vill ni ha SSO till Mediaflow också kan ni direkt gå till denna artikel istället

Innehåll

Generellt om SSO

Definitioner av begrepp

Teknisk information

Instruktioner

Begränsningar

 

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ändande 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 som skickas från IdP till SP.

Federationmetadata: XML-dokument som innehåller information om hur man kan autentisera mot en given tjänst. Används inom 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å distinktionen 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, 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 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 en Mediaflow portal

För att använda SSO med våra tjänster behöver kunden ha en Identity provider (IdP) som stödjer antingen SAML2 eller OpenID Connect.

Autentiseringen sker alltid hos kunden oavsett om inloggning sker mot kundens portal eller kundens Mediaflow-konto.  

När användaren har autentiserats av kundens IdP skickas de tillbaka till sin portal och vi kontrollerar då biljetten för att säkerställa att de kommer från rätt IdP. Vi tittar inte på de claims som skickas med här, så om ni bara vill ha SSO till portalen behöver ni inte skicka med det i biljetten.

Om ni vill begränsa vissa grupper av användare från att komma åt portalen trots att de ingår i ert AD så går det att göra på er sida genom att inte tillåta dessa grupper att använda applikationen.

 
 
 

 


Instruktioner

1. Hämta vår metadata från länken nedan

https://sso.mediaflowpro.com/metadata.xml

2. Skapa en SAML2 eller OpenID connect-leverantör i er IDP

Ni behöver inte lägga till några claims/attribut om ni bara vill ha SSO till portalen. 

3. Skicka över er federationmetadata till oss (för SAML2)

Vi lägger in det hos oss och skapar en testsida som vi skickar tillbaka till er. Testsidan används bara för att visa att ni kommer till er AD-inloggning. Sidan i sig är avskalad och visar egentligen bara om ni är autentiserade användare. Om ni inte skickat med några claims (för att SSO-inloggning bara ska ske mot portalen) så kommer testet att påpeka detta, men det kan vi ignorera. 

4. Återkom med utfall av testet och be oss sätta igång SSO för portalen

Vi låser nu er portal för omvärlden helt, och tillåter bara användare som kommer från ert AD och återkopplar till er när det är gjort.

 

Länkar till guidning i gränssnittet för hur det kan sättas upp i olika miljöer finns nedan.
Om det bara är SSO för portal kan ni som sagt bortse från de claims/attribut som finns med i dessa guider.

Guide för Azure AD

Guide för Lokalt AD (ADFS)


 

 

 

 


Begränsningar

Automatisk inhämtning av federationsmetadata

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 förändringar görs på er sida, t.ex. att certifikatet uppdateras behöver vi få den nya metadata-filen. 

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.