Lägg till filter

Filter används för att få tag i inloggningsinformation från HTTP-förfrågan. Det kan exempelvis vara frågan om att hämta parametrar eller värden från en cookie.

Denna information kommer sedan att användas  av modulerna för att utföra inloggningen mot exempelvis en katalogtjänst via LDAP.

Formulärfilter

Detta filter använder parametrar för att få tag i användarnamn och lösenord. Antingen via POST eller GET, vilket innebär att följande adress kan användas för att identifiera användaren:

BASIC

BASIC Authentication bygger på att webbläsaren skickar en HTTP-header som innehåller användarnamn och lösenord till servern.
Detta filter ska som standard vara med pga. exempelvis webdavklienter som endast kan hantera detta sätt att logga in. Här kan du läsa mer utförlig beskrivning om hur BASIC fungerar.

CAS/CAS2

CAS är en open source mjukvara för single sign-on (SSO) för webbapplikationer. Istället för att Sitevision hanterar inloggningen så görs Här kan du läsa mer om CAS Länk till annan webbplats, öppnas i nytt fönster..

Enkel konfiguration

• CAS login URL - måste anges (https://<cas-server>/cas/login)
• CAS service URL eller Client server name - måste anges, detta är adressen som ska användas vid redirect efter lyckad inloggning.
• CAS ticket validation URL - måste anges (https://<cas-server>/cas/serviceValidate)
  

CAS 3

CAS3 använder sig av SAML1.1 protokollet för att autentisera användare. Där ingår stöd för "attributes release".

Utförlig beskrivning av konfigurationsparametrarna Länk till annan webbplats, öppnas i nytt fönster.

CAS3

• Tolerance - Ange hur stor tidskillnad/drift som tillåts mellan Sitevision och CAS servern.
• CAS server login URL - Måste anges (https://<cas-server>/cas/login)
• Renew ticket on login - Ange om du vill att CAS-servern ska kräva ny autentisering även om användaren redan har en session med CAS-servern
  
• CAS server URL - CAS-serverns URL (https://<cas-server>/cas), måste anges
• Client service URL - URL:en som användaren ska omdirigeras till efter godkänd autentisering. Denna eller "Klientens servernamn" måste anges.
• Client server name - Ange servernamnet om du vill att användaren, efter godkänd autentisering, ska omdirigeras till den sida som användaren anropade. Denna eller "Klientens service URL" måste anges.
• Ignore certificate - Anges vid exempelvis testning om du vill slippa att installera CAS-serverns certifikat i Sitevision eftersom kommunikationen mellan Sitevision och CAS-server måste ske med https.
• Use SAML 1.1 - Ange om du vill använda SAML1.1 protokollet för kommunikation mellan Sitevision och CAS-server. I annat fall används CAS2.0.
• Populate shared password - (Ej obligatoriskt). Användare som autenticierats via CAS3 modulen populeras med detta lösenord för att ett eventuellt integrerat bakomliggande system ska kunna verifiera att användaren blivit inloggad.
• Auth-metod attribut - Vilket underliggande protokoll som används vid autentisering exempelvis SAML.

Klientadress

Klientadressfiltret används för att få tag i kilentens ip-adress som sedan kan användas för att tilldela läsrättigheter baserat på ip-adresser.

1. Använd X-Forwared-For-Header - För att identifiera original ip-adressen om du går via en brandvägg.

Konfigurerbart filter

Det konfigurerbara filtret kan användas exempelvis om du har en egen säkerhetslösning som det inte finns något färdigt filter för. Här kan du välja hur användarnamn, lösenord och authtype hämtas från http-requesten.

Följande typer är möjliga:

• none
• header
• parameter
• cookie
• konstant

MobilityGuard

Specialicerat filter för att hantera headers som kommer från säkerhetslösningen MobilityGuard Länk till annan webbplats, öppnas i nytt fönster..

Det spelar ingen roll i vilken ordning detta filter kommer i filterkedjan.

Portwise

Specialiserat filter för att hantera cookies från säkerhetslösningen PortWise.

1. Använd Portwise cookie för klientadress - Bockar du i denna ruta så skickas IP-adressen från klientadressen till Sitevision istället för att skicka Portwise IP-adress. Använder du denna så kan man exempelvis nyttja IP-inloggning, logga vilken IP-adress som användare kommer ifrån.

OpenId

OpenId är en standard som möjliggör en federerad inloggning*. Används ofta för att ge användarna enkel inloggning till en community eller blogg. Används bland annat av Google, Facebook och Yahoo. Läs mer på http://openid.net/ Länk till annan webbplats, öppnas i nytt fönster.

* Federerad inloggning= en användare kan logga in hos en organisation/tjänst med en identitet från en annan organisation eller identitetsutgivare.

Svensk e-identitet

I Sitevision finns en koppling till Svensk e-identitets ”molnbaserade” inloggningstjänster. När inloggningsmodulen i Sitevision används anropas Svensk e-identitets inloggningstjänst som utför inloggningen av användare enligt de regler som definierats. Läs mer om Svensk e-identitet.

Kerberos

Microsoft har gjort ett protokoll SPNEGO som möjliggör automatisk inloggning över Kerberos.

1. Debug - Aktivera för att underlätta vid felsökning.
2. Allowed addresses - Vilka ip-adresser som ska få automatisk inloggning. Har du flera ip-adressområden så lägger du till dem med ett kommatecken mellan varje område.
3. Service principal - SPN, det tjänstekonto som används.
4. KDC - Står för Key Distribution Center, vanligtvis domänkontrollant.
5. Realm - Måste matcha domännamn på webbplatsen
6. User-Agent filter (regexp) - Här kan du ställa in ett filter om du exempelvis vill kräva att en viss webbläsare ska användas. Typ *firefox.*
7. Service password - Lösenordet för AD-konto som angivit för Kerberos.
8. Domain - Domännamn på webbplatsen.

NTLM

NTLM är en proprietär inloggningsmetod som används framförallt av Internet Explorer. Denna inloggningsmetod möjliggör automatisk inloggning mot Sitevision.

Det finns vissa begränsningar:

• NTLM fungerar inte om det finns en webbproxy mellan användaren och Sitevision-servern
• Den fungerar endast om "Integrerad Windows-autentisering" är aktiverad i Internet Explorer.
• Adressen som används för att nå Sitevision-servern måste finnas med i zonen "Lokalt intranät" i Internet Explorer. Annars öppnas en windows-inloggningsruta där man måste logga in manuellt.
• Cachning av lösenord i lokal profil gör att lösenordsbyte i vissa miljöer inte slår igenom i NTLM-inloggningen.
• Användarna som loggar in via denna inloggningsmetod måste finnas i den första katalogtjänsten om det finns flera katalogtjänster.

1. Använd domännamn för kataloguppslag - Bocka i denna om du vill använda domännamnet.
2. CIFS-server - Sitevision autentiserar användaren mot denna server via CIFS-protokollet. Oftast är detta samma server som katalogtjänsten finns på.
3. Tillåtna adresser - Här anger du de ip-adresser som ska beröras av denna inloggningsmetod. I bilden ovan visas ett exempel på hur ett ip-range specificeras korrekt. Har du flera ip-range så ska de separeras med kommatecken. (OBS! Inga mellanslag någonstans). Om fältet lämnas tomt räknas alla ip-adresser som tillåtna.

Mer information om NTLM

Secure cookie

Filtret hanterar redirects för automatisk inloggning via säker cookie (se secure cookie-modul)

Detta filter måste finnas konfigurerat om Secure cookie inloggningen ska fungera.

SAML 2

SAML står för Security Assertion Markup Language och är en XML-baserad öppen standard för att utbyta autentisering och behörigheter.

SAML är en federerad inloggningsmetod som ordnar egen inloggning mot AD utan att behöva direkt kontakt med AD. Lägg till ett SAML-filter för att göra inställningar:

• ConsumerService(Binding): HTTP-POST
• Standard felmeddelande - Om du vill ha eget felmeddelande istället för systemets felmeddelande.
  
• Inloggningsadress IDP - Fyll i denna om du använder IDP-initierad inloggning så redirectad användaren till IDP:n innan inloggning i Sitevision.
• Assurance level: 0
• Domännamn: För att kunna ha flera olika SAML konfigurationer på samma site så behöver du fylla i domännamn för att koppla konfigurationen mot ett domännamn.
• Keystore för certifikat: Bläddra fram keystore-filen som du laddat upp i filarkivet i Sitevision. Keystore-filen finns i zip-filen (som laddas hem via <adress>/saml/download).
• Lägg till NameID Policy i authenticeringsanropet - Om IDP:n kräver NameID policy behöver du bocka i denna ruta exempelvis Apache Shibboleth
• Ignorera certifikat - Om det går bra med självsignerade certifikat så bocka i denna ruta.
• Lösenord för certifikat: Keystore password (genereras av Sitevision vid SAML-konfiguration)
• Använd SHA256 för certifikat - Bocka i denna för att använda SHA 256-kryptering av keystoren i SAML-ticketen. Om du inte bockar i denna används den äldre metoden SHA 1 för kryptering.
• Adress till felsida - Om du vill ha en egen felsida istället för felmeddelande.
• Provider-metadata - Klistra in innehållet från SP-metadatafilen här.
• Hämta IDP-metadata via URL (hämtas dagligen) - Om du hellre vill ange en adress till IDP-metadata. Fördelen med detta är att informationen uppdateras varje natt kl 05.
• IDP-metadata: Om du inte använder en adress till IDP-metadatat så klistrar du in innehållet från IDP-metadatafilen här.
• Registrera SAML cookie -Om du använder SAML och vill kunna spara #option för att komma till rätt ställe, så måste du bocka i denna ruta för att registrera en cookie.
  • Kakan oiosaml-fragment registreras då som en nödvändig cookie på Webbplatsinställningar -> Funktioner -> Cookies.
• Hämta IDP-metadata - Hämtar IDP-metadatat direkt från den adress som är angiven i fältet (Hämta IDP-metadata URLmetadata via URL (hämtas dagligen)).

OpenID Connect

OpenID Connect är ett autentiseringslager som ligger ovanpå auktoriseringsstandarden OAuth 2.0. Det används för att skapa federerade inloggningar.

Tekniken är JSON-baserad och kräver mindre nätverkstrafik än sitt äldre syskon SAML2.

• Adress för OpenID Connect Issuer: Adressen till den IDP som hanterar inloggningen av användare
• Program-ID: Ange det program-id du fått när du registrerat appen i IDP:n.
• Klienthemlighet: Ange den nyckel som du genererat för appen i din IDP
• Domännamn: För att kunna ha flera olika OpenID Connect-konfigurationer på samma webbplats så behöver du fylla i domännamn för att koppla konfigurationen mot ett domännamn.
• Utloggningsadress för Single Sign Out: Ange adress dit användaren kommer skickas efter utloggning i SiteVision. Om inget värde anges kommer SiteVision leta efter värdet "end_session_endpoint" i OpenID Providerns metadatadokument
• Adress till felsida - Om du vill ha en egen felsida istället för felmeddelande.
• Standard felmeddelande - Om du vill ha eget felmeddelande istället för systemets felmeddelande.

JSON Web Token

JSON Web Token kan användas för att logga in användare utifrån en signerad JSON Web Token (JWT). Ett vanligt flöde är att terminera trafiken i en lastbalanserare/proxy för att initiera inloggning. Den inloggade användaren skickas sedan till Sitevision tillsammans med en JWT som identifierar användaren.

Filtret hämtar en signerad JWT från en header. Denna token valideras utifrån fördefinierade publika nycklar innan inloggning kan tillåtas.

• Namn på header för JSON Web Token: Namnet på den header där JWT:n skickas in
• Issuer URL: Adress till den server som utfärdat JWT:n
• Audience: Identifierar den som ska ta emot JWT:n. Ofta ett klient-ID eller liknande. Ska anges om inkommande token är en standardiserad ID-token
  

Valideringsmetod:

• Hämta från OpenID Connect Metadata: Publika nycklar hämtas från det metadatadokument som publiceras på <Issuer URL>/.well-known/openid-configuration
• Hämta från JSON Web Key Set URL : Publika nycklar hämtas från denna adress
• Hämta från JSON Web Key URL : Publik nyckel hämtas från denna adress. Använd $jwkKey för att ange var ev. nyckelnamn ska stå.
• Använd JSON Web Key: En fast nyckel kommer användas