In een aantal blog posts zal ik meer uitleg geven over ADFS, WIF en Claims based security. Wat is wat en hoe gebruik ik dit in mijn Enterprise omgevingen, in de Cloud en in SharePoint.
Deel 1: Wat moet ik met ADFS en WIF en Claims (dit artikel)
Deel 2: Wat is een Claim
Bij het maken van web applicaties lopen we telkens tegen een aantal security problemen aan:
- Intranet of een Internet applicatie
- Geen/moeilijk hergebruik van login gegevens
- Interop tussen .NET en JAVA omgevingen
- Duplicatie van accounts over organisaties heen
- Firewalls en trusts
Hoe kan ik nu een applicatie maken die klaar is om vele jaren te draaien, ongeacht de locatie (lokaal, gehost, cloud) en hoe koppel ik daar gebruikers aan vast terwijl ik niet weet of dat interne of internet gebruikers zijn. We gaan de onderdelen langs:
Intranet of een Internet applicatie
De keuze intranet applicatie of internet applicatie maken we heel snel in onze .NET omgevingen. Voor het intranet kiezen we voor Windows Authentication en laten we alle users via een Active Directory (AD) inloggen. Voor internet scenario’s kiezen we Forms based Authentication en aan de achterkant een Database of LDAP store voor alle gebruikers gegevens. Een migratie van een intranet naar een internet applicatie is hiermee al een stuk moeilijker geworden.
Claims Based Security lost dit op door zowel op het intranet als het internet met Claims te werken. Zo kan een applicatie eenvoudig van intern naar een extranet (of internet) omgeving verplaatst worden. Ook kun je inloggen met je eigen gebruikers op een hosted Sharepoint of BPOS omgeving.
Geen/moeilijk hergebruik van login gegevens
Voor iedere applicatie bouwen we opnieuw loginschermen, gebruikers databases, rollen en verantwoordelijkheden. Wat we willen hebben is een herbruikbaar authenticatie en authorizatie systeem. Het aanloggen gebeurd via een centrale hub (dit is de ADFS server in het geval van een Active Directory) en vervolgens komt er een claim binnen op de applicatie.
Iedere applicatie hoeft alleen maar de claim uit te pakken, in .NET gebeurd dit met de WIF module (Windows Identity Foundation)
Interop tussen .NET en JAVA omgevingen
Het aansluiten van JAVA applicaties op een Windows omgeving is ook vaak een leuke uitdaging. Ga ik mijn Java app laten draaien op IIS, schaf ik een dure applicatie server aan met een koppeling naar een LDAP server.
Met Claims krijg ik in mijn Java applicatie een SAML claim (Security Assertion Markup Language) binnen. Hierin vind ik de gegevens van de aangelogde persoon (naam, rollen, etc) in een beveiligd XML bestand. De applicatie dient deze claim te controleren en uit te pakken (b.v. met OpenSAML)
Duplicatie van accounts over organisaties heen
Bij een extranet maken we voor onze klanten vaak een 2e account aan (b.v. in onze eigen Active Directory). Vervolgens zal de medewerker bij de klant dit account gaan gebruiken in onze applicatie. Tot zo ver geen problemen…
Wat nu als deze medewerker uit dienst gaat. Vaak zal deze het wachtwoord op een post-it overdragen aan zijn opvolger, maar hoe garandeer ik dat ALLEEN de opvolger nog in kan loggen. De oplossing hiervoor vinden we in het aanbrengen van een trust tussen de 2 bedrijven, zodat iedere externe medewerker met zijn eigen (lokale) account kan aanloggen. Gaat hij uit dienst, dan wordt zijn account ingetrokken en is de extranet applicatie ook niet meer beschikbaar voor hem.
Firewalls en trusts
Het opzetten van een trust tussen 2 bedrijven kan al jaren op Active Directory niveau, maar geen enkele systeembeheerder zal dat zomaar toe staan. Ook op Firewalls staan alle poorten hier vaak voor dicht. Met WS-Federation kan ik een trust aanmaken tussen meerdere ADFS (of andere pakketten van andere leveranciers) servers, waarbij de beheerder 100% controle heeft over welke claims we accepteren uit het andere domein.
Om door de Firewall te komen is er een speciale ADFS Proxy, deze fungeert als veilig doorgeefluik tussen het internet en de interne Active Directory.
Wat staat er in een Claim
Dat is het mooie aan Claims, dat bepaal je zelf per applicatie. Zo kan dat de gebruikersnaam en al zijn rollen zijn, maar ook een personeelsnummer of klantnummer. Een claim kan ook een eigen machtigingen structuur bevatten, zo kunnen we complexere rechten ook meegeven (zoals tijden waarop iemand een bepaalde actie mag doen, voor welke (business) unit)