# Domein 5-I: Identity and Access Management (IAM) 


Identificatie is het verifiëren van identiteiten t.b.v.:
* Registratie (van de persoon zelf)
* Genereren dan wel uitgeven van authenticatiemiddelen (bijv. een login-account en toegangspas)

Identificatie moet gebeuren met een bepaald zekerheidsniveau.
(Check bijv. eIDAS)

Identificatie moet afgerond zijn om authenticatie mogelijk te maken.

Authenticatie is het verifiëren van identiteit tbv het verkrijgen van toegang (tot ruimtes of informatie).
Daarvoor heb je een authenticatie middel nodig.

SFA (single factor authentication) pas je toe bij ‘laag risico’ informatie. Er is dan 1 bewijsfactor, bijv. een wachtwoord of een vingerafdruk.

Voor vertrouwelijke informatie kies je voor MFA (multi-factor authentication).
Bij MFA moet je om toegang te krijgen tenminste 2 bewijsfactoren aanleveren *uit twee verschillende categorieën*.

Categorieën van bewijsfactoren:
1. Kennis (bijv. Pin-code, wachtwoord, antwoord op een geheime vraag)
2. Bezit (token, pasje, smartphone)
3. Biometrische of gedragskenmerken (vingerafdruk, iris-scan, face-scan, retina-scan is het meest betrouwbaar en daarmee populair in de militaire wereld, ritme en intensiteit van typen (type dynamics, swipe dynamics), manier van lopen (gait))
4. Steeds vaker wordt ook de context van de gebruiker betrokken (bijv. IP adress, location, device type, tijdstip).

Nadelen van authenticatie met biometrische kenmerken:
- Niet vervangbaar indien gecompromitteerd, daarom sterke voorkeur voor lokaal opslaan
* lokaal opslaan kan niet voor bijvoorbeeld toegang tot gebouwen. 
* Aan verandering onderhevig (ouderdom, kwetsuren, etc.), risico op false reject.

Biometrische authenticatie zoekt de balans tussen false reject rates (door te strenge afstelling) en false accept rates (door te ruime afstelling).

2FA, MFA en strong authentication zijn synoniemen.

Belangrijkste eis aan een wachtwoord is voldoende lengte (zeg 14). Periodiek wijzigen, vreemde karakters: het is allemaal achterhaald.

NIST SP 800-63c/d en Gartner (zet de docent nog op Ilias) vinden dat ook. CISSP zit nog op het oude spoor!

FIDO alliance (is Fast IDentity Online) ontwikkelt standaarden. Één daarvan is het gebruik van een geregistreerd digitaal certificaat, gebonden aan jouw identiteit.
Je registreert dan je public key bij de server waar je toegang toe wilt. De server stuurt je een challenge die je versleutelt met je eigen private key. De server ontsleutelt dan dat bericht met jouw public key en de authenticatie is geslaagd.

## Single Sign-On (SSO)
Toegang tot alle achterliggende applicaties door eenmalig het authenticatie process te doorlopen.

Vormen van SSO:
* Kerberos (MS Windows netwerken). Een Windows server fungeert als Key Distribution Center (KDC) ofwel Authentication Server. Je logt in op de KDC en die stuurt jouw een Ticket Granting Ticket die in het werkgeheugen van de client wordt opgeslagen (zwakheid 1). Als je vervolgens de Exchange server wilt benaderen stuur je je TGT naar de KDC, die je vervolgens een Service Ticket toestuurt. Met deze ST krijg je toegang tot de Exchange server. Die KDC is een single point of failure. Omdat er een trust-relatie nodig is tussen de KDC en de services-servers (die immers de ST’s moeten kunnen verifiëren) werkt Kerberos niet met cloud services. 
* WebSSO. Inloggen op een Reverse Proxy die de authenticatie afhandelt met de Authentication Server (waar jouw identiteit bekend moet zijn). Via de Reverse Proxy krijg je dan toegang tot de verschillende (web-) domeinen.
* Enterprise SSO. Moet ook de toegang tot allerhande legacy systemen verzorgen. Gebruiker logt in bij SSO systeem (bevat jouw login information in secret store). SSO systeem logt jouw vervolgens in op alle achterliggende systemen. Er is meestal geen goede business case meer voor. Je vindt het vooral nog in de zorg, waar als eis geldt dat de medicus zonder moeite bij verschillende legacy systemen moet kunnen.
* Cross-domain SSO / federated identity: toegang tot systemen/services over organisaties heen (bijv. Externe cloud services). Een bekend voorbeeld is DigiD. Je benadert de server van de Belastingdienst. Die stuurt je door naar de Identity Provider (IDP), DigiD.nl, waar in een eerder stadium het identificatieproces heeft plaatsgevonden, en waar je dus geregistreerd staat. Deze zal voortaan de authenticatie afhandelen. Na een geslaagde authenticatie stuurt de IDP jou de SAML assertion of -token (Security Assertion Markup Language). Die assertion stuur je dan naar een Service Provider of ‘relying party’ (in deze de Belastingdienst, of het UWV) die de assertion weer verifieert bij de IDP. Daarna krijg je toegang. SAML is afkomstig van OASIS (check afko)
* Ander voorbeeld van federated identity: Gebruiker logt in op Windows server (de IDP). Die verstrekt SAML-assertion, daarmee kan ik dan resources benaderen op de Azure Cloud, waar dan Office365 beschikbaar is. Deze MS implementatie van SAML noemt Microsoft de Active Directory Federation Service.

De SAML assertion is een representatie van de login gegevens, maar bevat zelf waardeloze gegevens. Het is een verwijzing naar, niet de login informatie zelf. Het is het bewijs dat de authenticatie bij de IDP geslaagd is.
Deze methode is kwetsbaar voor een Replay-attack (binnen dezelfde sessie, na onderschepping SAML assertion); is te voorkómen met TLS.

In de Microsoft wereld zie je dat login gegevens gesynchroniseerd worden tussen de Windows server en de Azure AD, met de tool AD-connect.

OpenID Connect is de moderne standaard voor Cross-domain SSO
Bestaat uit 2 subspecificaties: OpenID voor authenticatie, OAuth voor autorisatie.
Werking: ik bezoek de website van de SP/rp. Daarin zie ik: log in met je Facebook account. Facebook fungeert dan als IDP. Bij de IDP mag ik dan aangeven, welke gegevens gedeeld mogen worden met de SP. Vervolgens wordt een JSON webtoken (JWT) gegenereerd die deze gegevens representeert (maar in zichzelf betekenisloos is). Vergelijkbaar met SAML maar gemakkelijker te implementeren.
Issue is dat de originele identificatie (bij Facebook in dit voorbeeld) niet heel betrouwbaar is.
Microsoft ondersteunt dit overigens ook, en binnen de bedrijfsomgeving (van de werkgever) is de identificatie natuurlijk veel  beter geregeld.

OpenID Connect maakt gebruik van RESTful API’s
REST = Representational State Transfer
Gebruikt eenvoudige commando’s gebaseerd op HTTP verbs (GET, PUT)

## Sheet 70:
“Secrets are based on symmetric or asymmetric keys”
Voorbeeld asymmetrisch:
Een smartcard bevat een chip met daarop een digitaal certificaat. Dat certificaat bevat jouw public key. Op de chip staat ook je private key.
Server stuurt je een challenge, die wordt door de smartcard versleuteld met jouw private key. De versleutelde challenge wordt samen met het digitaal certificaat verstuurd naar de server. De Public key uit het certificaat wordt dan door de server gebruikt om de challenge weer te ontsleutelen.
Voorbeeld symmetrisch:
De challenge wordt nu client-side versleuteld met een key, die dus eerder al bekend moet zijn bij de server om ontsleutelt te kunnen worden (off-band via een ander veilig kanaal). Wordt toegepast bij authenticatie tussen systemen in de financiële wereld.
