Legg til filtre

Filtre brukes til å hente innloggingsinformasjon fra HTTP-forespørselen. Det kan for eksempel dreie seg om å hente parametere eller verdier fra en informasjonskapsel.

Denne informasjonen brukes deretter av modulene til å utføre påloggingen til for eksempel en katalogtjeneste via LDAP.

Skjemafilter

Dette filteret bruker parametere for å hente inn brukernavn og passord. Enten via POST eller GET, noe som betyr at følgende adresse kan brukes til å identifisere brukeren:

BASIC

BASIC Autentisering er basert på at nettleseren sender en HTTP-header som inneholder brukernavn og passord til serveren.
Dette filteret bør være inkludert som standard fordi for eksempel webutviklerklienter bare kan håndtere denne måten å logge inn på. Her kan du lese en mer detaljert beskrivelse av hvordan BASIC fungerer.

CAS/CAS2

CAS er en programvare med åpen kildekode for single sign-on (SSO) for webapplikasjoner. I stedet for at Sitevision håndterer påloggingen, gjøres det Her kan du lese mer om CAS Lenke til et annet nettsted, åpnes i nytt vindu..

Enkel konfigurasjon

• CAS-påloggings-URL - må oppgis (https://<cas-server>/cas/login).
• CAS-tjeneste-URL eller klientservernavn - må angis, dette er adressen som skal brukes til omdirigering etter vellykket pålogging.
• CASticket validation URL - må oppgis (https://<cas-server>/cas/serviceValidate).
  

CAS 3

CAS3 bruker SAML1.1-protokollen til å autentisere brukere. Dette inkluderer støtte for "frigivelse av attributter".

Detaljert beskrivelse av konfigurasjonsparametrene Lenke til et annet nettsted, åpnes i nytt vindu.

CAS3

• Toleranse - Angi hvor stor tidsforskjell/drift som tillates mellom Sitevision og CAS-serveren.
• CAS-serverenspåloggings-URL - Må oppgis (https://<cas-server>/cas/login).
• Forny billett ved pålogging - Angi om du vil at CAS-serveren skal kreve ny autentisering selv om brukeren allerede har en økt med CAS-serveren.
  
• CAS-server-URL - URL-adressen til CAS-serveren (https://<cas-server>/cas) må oppgis.
• Client service URL - URL-adressen som brukeren skal omdirigeres til etter vellykket autentisering. Denne eller "Navn på klientserver" må angis.
• Navn på klientserver - Skriv inn servernavnet hvis du vil at brukeren, etter vellykket autentisering, skal omdirigeres til siden brukeren ba om. Denne eller "URL-adressen til klienttjenesten" må angis.
• Ignorer sertifikat - Angis for testing, for eksempel hvis du vil unngå å installere CAS-serverens sertifikat i Sitevision fordi kommunikasjonen mellom Sitevision og CAS-serveren må skje med https.
• Bruk SAML 1. 1 - Angi om du vil bruke SAML1.1-protokollen for kommunikasjon mellom Sitevision og CAS-serveren. Hvis ikke, brukes CAS2.0.
• Fyll ut delt passord - (Ikke påkrevd). Brukere som autentiseres via CAS3-modulen, fylles med dette passordet slik at et eventuelt integrert underliggende system kan verifisere at brukeren er logget inn.
• Auth-method-attributt - Hvilken underliggende protokoll som brukes forautentisering, for eksempel SAML.

Klientadresse

Klientadressefilteret brukes til å finne kildens IP-adresse, som deretter kan brukes til å tildele leserettigheter basert på IP-adresser.

1. Bruk X-Forwared-For-Header - For å identifisere den opprinnelige IP-adressen hvis du går gjennom en brannmur.

Konfigurerbart filter

Det konfigurerbare filteret kan for eksempel brukes hvis du har en egen sikkerhetsløsning som det ikke finnes noe ferdig filter for. Her kan du velge hvordan brukernavn, passord og authtype skal hentes fra http-forespørselen.

Følgende typer er mulige:

• ingen
• overskrift
• parameter
• informasjonskapsel
• konstant

MobilityGuard

Spesialisert filter for å håndtere overskrifter som kommer fra sikkerhetsløsningen MobilityGuard Lenke til et annet nettsted, åpnes i nytt vindu..

Det spiller ingen rolle i hvilken rekkefølge dette filteret kommer i filterkjeden.

Portwise

Spesialisert filter for å håndtere informasjonskapsler fra PortWise-sikkerhetsløsningen.

1. Bruk Portwise-informasjonskapsel for klientadresse - Hvis du merker av i denne boksen, sendes IP-adressen fra klientadressen til Sitevision i stedet for å sende Portwise-IP-adressen. Hvis du bruker dette, kan du for eksempel bruke IP-pålogging og logge hvilken IP-adresse brukeren kommer fra.

OpenId

OpenId er en standard som muliggjør føderert innlogging*. Brukes ofte for å gi brukerne én enkelt innlogging til et nettsamfunn eller en blogg. Brukes blant annet av Google, Facebook og Yahoo. Les mer på http://openid.net/ Lenke til et annet nettsted, åpnes i nytt vindu.

* Federert pålogging = en bruker kan logge på en organisasjon/tjeneste med en identitet fra en annen organisasjon eller identitetsleverandør.

Svensk e-identitet

I Sitevision finnes det en kobling til svenske e-identitets "skybaserte" innloggingstjenester. Når påloggingsmodulen i Sitevision brukes, anropes den svenske e-identitetens påloggingstjeneste, som utfører påloggingen av brukere i henhold til de definerte reglene. Les mer om svensk e-identitet.

Kerberos

Microsoft har laget en protokoll SPNEGO som muliggjør automatisk pålogging via Kerberos.

1. Feilsøking - Aktiver for å lette feilsøking.
2. Tillatte adresser - Hvilke IP-adresser som skal motta automatisk pålogging. Hvis du har flere IP-adresseområder, legger du dem til med et komma mellom hvert område.
3. Service principal - SPN, tjenestekontoen som brukes.
4. KDC - står for Key Distribution Centre, vanligvis en domenekontroller.
5. Realm - Må samsvare med domenenavnet på nettstedet.
6. User-Agent-filter (regexp) - Her kan du angi et filter hvis du for eksempel vil kreve at en bestemt nettleser skal brukes. Skriv inn *firefox.*
7. Tjenestepassord - Passordet for AD-kontoen som er angitt for Kerberos.
8. Domain - domenenavnet til nettstedet.

NTLM

NTLM er en proprietær påloggingsmetode som primært brukes av Internet Explorer. Denne påloggingsmetoden muliggjør automatisk pålogging til Sitevision.

Det finnes noen begrensninger:

• NTLM fungerer ikke hvis det er en webproxy mellom brukeren og Sitevision-serveren.
• Den fungerer bare hvis "Integrert Windows-autentisering" er aktivert i Internet Explorer.
• Adressen som brukes for å få tilgang til Sitevision-serveren, må være inkludert i sonen "Lokalt intranett" i Internet Explorer. Ellers åpnes en Windows-påloggingsboks der du må logge på manuelt.
• Bufring av passord i den lokale profilen betyr at passordendringer i noen miljøer ikke gjenspeiles i NTLM-påloggingen.
• Brukere som logger på med denne påloggingsmetoden, må være i den første katalogtjenesten hvis det finnes flere katalogtjenester.

1. Bruk domenenavn for katalogoppslag - Kryss av hvis du vil bruke domenenavnet.
2. CIFS-server - Sitevisionautentiserer brukeren mot denne serveren via CIFS-protokollen. Dette er vanligvis den samme serveren som katalogtjenesten ligger på.
3. Tillatte adresser - Her angir du IP-adressene som skal påvirkes av denne påloggingsmetoden. Bildet over viser et eksempel på hvordan et IP-område angis korrekt. Hvis du har flere IP-områder, skal de skilles med komma. (MERK! Ingen mellomrom noe sted). Hvis feltet er tomt, regnes alle IP-adresser som tillatte.

Mer informasjon om NTLM

Secure Cookie

Filteret håndterer viderekoblinger for automatisk pålogging via sikker informasjonskapsel (se modulen for sikker informasjonskapsel).

Dette filteret må være konfigurert for at pålogging via sikker informasjonskapsel skal fungere.

SAML 2

SAML står for Security Assertion Markup Language og er en XML-basert åpen standard for utveksling av autentisering og autorisasjoner.

SAML er en føderert påloggingsmetode som organiserer selvpålogging til AD uten behov for direkte kontakt med AD. Legg til et SAML-filter for å gjøre innstillinger:

• ConsumerService(Binding): HTTP-POST
• Standard feilmelding - Hvis du vil ha din egen feilmelding i stedet for systemets feilmelding.
  
• Påloggingsadresse IDP - Fyll ut dette hvis du bruker IDP-initiert pålogging, slik at brukeren omdirigeres til IDP-en før innlogging på Sitevision.
• Sikringsnivå: 0
• Domenenavn: For å kunne ha flere forskjellige SAML-konfigurasjoner på samme nettsted må du fylle ut domenenavnet for å knytte konfigurasjonen til et domenenavn.
• Keystore for sertifikater: Bla gjennom keystore-filen som du lastet opp til filarkivet i Sitevision. Keystore-filen ligger i zip-filen (lastet ned via <address>/saml/download).
• Legg til NameID-policy i autentiseringsanropet - Hvis IDP-en krever NameID-policy, må du merke av i denne boksen, for eksempel Apache Shibboleth.
• Ignorer sertifikater - Hvis du godtar selvsignerte sertifikater, merker du av i denne boksen.
• Passord for sertifikater: Keystore-passord (generert av Sitevision under SAML-konfigurasjonen).
• Bruk SHA256 for sertifikat - Kryss av her for å bruke SHA 256-kryptering av nøkkellageret i SAML-tokenet. Hvis du ikke merker av for dette, brukes den eldre SHA 1-metoden for kryptering.
• Feilsideadresse - Hvis du vil ha en egen feilside i stedet for en feilmelding.
• Provider metadata - Lim inn innholdet fra SP-metadatafilen her.
• IDP-metadata (URL) - Hvis du foretrekker å angi en adresse for IDP-metadataene. Fordelen med dette er at informasjonen oppdateres hver natt kl. 05:00.
• IDP-metadata: Hvis du ikke bruker en IDP-metadataadresse, limer du inn innholdet fra IDP-metadatafilen her.
• Registrer SAML-informasjonskapsel - Hvis du bruker SAML og vil kunne lagre #option for å komme til riktig sted, må du krysse av i denne boksen for å registrere en informasjonskapsel.

Informasjonskapselen oiosaml-fragment vil da bli registrert som en obligatorisk informasjonskapsel i Nettstedsinnstillinger -> Funksjoner -> Informasjonskapsler.

OpenID Connect

OpenID Connect er et autentiseringslag på toppen av autorisasjonsstandarden OAuth 2.0. Det brukes til å opprette fødererte pålogginger.

Teknologien er JSON-basert og krever mindre nettverkstrafikk enn sin eldre søster SAML2.

• Adresse tilOpenID Connect-utsteder: Adressen til IDP-en som håndterer påloggingen av brukere.
• Applikasjons-ID: Skriv inn applikasjons-ID-en du mottok da du registrerte appen i IDP-en.
• Client Secret: Skriv inn nøkkelen du genererte for appen i IDP-en.
• Domenenavn: For å kunne ha flere forskjellige OpenID Connect-konfigurasjoner på samme nettsted må du fylle ut domenenavnet for å knytte konfigurasjonen til et domenenavn.
• Feilsideadresse - Hvis du vil ha en egen feilside i stedet for en feilmelding.
• Standard feilmelding - Hvis du vil ha en egen feilmelding i stedet for systemets feilmelding.

JSON Web Token

JSON Web Token kan brukes til å logge inn brukere basert på et signert JSON Web Token (JWT). En vanlig flyt er å terminere trafikken i en lastbalanser/proxy for å starte påloggingen. Den innloggede brukeren sendes deretter til Sitevision sammen med en JWT som identifiserer brukeren.

Filteret henter en signert JWT fra en header. Dette tokenet valideres mot forhåndsdefinerte offentlige nøkler før innlogging kan tillates.

• JSON Web Token header name: Navnet på overskriften derJWT-en sendes inn.
• Issuer URL: Adressen til serveren somutstedte JWT-en.
• Audience: Identifiserer personen som skal motta JWT-en. Ofte en klient-ID eller lignende. Angis hvis det innkommende tokenet er et standardisert ID-token.
  

Valideringsmetode:

• Hent fraOpenID Connect Metadata: Offentlige nøkler hentes fra metadatadokumentet som er publisert på <Issuer URL>/.well-known/openid-configuration.
• Get fromJSON Web Key Set URL : Offentlige nøkler hentes fra denne adressen.
• Retrieve from JSONWeb Key URL: Offentlige nøkler hentes fra denne adressen. Bruk $jwkKey til å angi hvor et eventuelt nøkkelnavn skal være.
• Use JSON Web Key: En fast nøkkel vil bli brukt.