Business driver was er één van de onderwerpen, waarom zou je aan federated identity beginnen.
Allereerst moet natuurlijk de vraag beantwoord worden wat is nu eigenlijk federated identity. Deze vraag werd op zich niet echt beantwoord maar zal uitleggen wat ermee bedoeld wordt.
Als voorbeeld: waar het hier om gaat is dat een organisatie niet alle gebruikers bij een zakenrelatie wil registreren. Als het om één relatie gaat is dat op zich geen probleem maar heb je veel zaken relaties dan wordt het een probleem alle gebruikers van deze relatie die toegang tot jou applicatie willen te registreren.
Om nu toch de gebruikers van deze relatie toegang te geven op jou applicatie kun je bijvoorbeeld vertrouwen op een aantal gegevens die door de zakenrelatie worden meegestuurd als toegang gezocht wordt tot.
Bijvoorbeeld hier is een gebruikers en dit is zijn ID en zijn rol binnen de organisatie van de zaken relatie. Op basis van ID en rol wordt toegang verleend tot.
Dit kan alleen op basis van vertrouwen in de zakenrelatie
Het bespaard het bedrijf de registratie van alle gebruikers van de zakenrelatie, dit betekend een vermidering van de beheerlast, beheer vind plaats bij de relatie.
Om dit mogeliijk te maken zijn allerlei afspraken, protocollen en standaarden noodzakelijk. In de sessies was het belangrijkste de onderliggende afspraken waarop het vertrouwen gebasseerd is onderbelicht. De protocollen en standaarden kwamen uitgebreid aan bod. dit maakte het minder interessant omdat dat prima op het internet verkrijgbare informatie is.
Verder werd een aantal federatieconcepten uitgelegd, zoals iDP (identity provider federation) SP (Service Provider federation ) en Federated Identity Community.
Voornaamste aandachtspunt is volgens mij het vaststellen van het niveau van vertrouwen. Alle concepten gaan uit van authenticatie maar het moeilijkst te regelen is de autorisatie. Dat laatste schieten de protocollen op dit moment nog in te kort.
Belangrijkste standaarden zijn:
- SAML (Security Assertions Markup Language) Identity Federation gebasseerd op het uitwisselen van SAML tokens
- WS-Fed (Web Services Federation) Een meer generiek framewerk gebasseerd op WS-Trust dat meerdere token typen ondersteund.
- WS-SX (Web Services Secure Exchange) is een uitbreiding op de WS-Security standaard wat het mogelijk maakt vertouwde SOAP berichten uit te wisselen. Eigenlijk is het een uitbreiding op WS-Trust, WS-SecurityPolicy en WS-SecureConversation
Namelijk het oprichten van een Special Intrest Group
Die zich bezig houdt met het beschrijven van een:
- Identity Assurance Framework
- Identity Governace Framework
In welke mate kan ik vertrouwen op mijn Identity provider en afspraken over de gegevens die meegestuurd worden, hoe lang worden deze bewaard waarvoor zijn ze bestemd en mogen ze gebruikt worden.
Allerlei vraagstukken die als het gaat om de wet bescherming persoonsgegevens van belang zijn. Ze geven dus meer controle aan de eigenaar van deze gegevens over het gebruik van zijn gegevens. Dit zijn dus frameworks die User Centric Identity Management ondersteunen. Iets wat tijdens deze presentaties niet aan bod is gekomen
8 opmerkingen:
He Rob, leuk verhaal om te lezen. je schrijft dat erveel aandacht is voor authenticatie maar dat het werkelijke probleem bij autorisatie ligt. Komt dit later nog aan bod bij de conferentie?
ps. valt autorisatie zich wel vangen in (technische) protocollen en standaarden zoals bij authenticatie?
Daar zit hem dus het probleem bij federatie. Hoe regel je met derden wat een geautenticeerd persoon of applicatie mag.
Basis ja dat mag wordt wel ondersteund en er komt meer en meer attribute ondersteuning binnen de standaarden maar wordt het nog niet gebruikt.
De verschillende standaarden (en daar zit het probleem) zijn niet gelijk. de eerder genoemde ondersteunen verschillende functionaliteiten. Maar zelfs binnen één standaard zijn er verschillen bv SAML 1.0, 1.1 en 2.0 zijn niet compatible met elkaar.
Dat betekent dat alleen de basis functionaliteit uitwisselbaar is. Laat staan als de werelden die elkaar moeten vertrouwen een verschillende standaard gebruiken.
Daarom is het bij het maken van keuzes belangrijk dat een Security Token Service wordt ondersteund. Deze service ondersteund veel Security tokens en is daarmee bijvoorbeeld in staat een Kerberos ticket om te zetten naar SAML
Hej Rob, interessante blog entry. Voor mij een handige aanzet om wat meer research te doen over de genoemde concepten. Bij het lezen vroeg ik mij echter af in welke mate die standaarden zoals SAML/WS-Fed en WS-SX reeds in de praktijk zijn geimplementeerd?
Erg weinig dus
Helaas
Als ik je blog goed begrijp zitten we hier met een behoefte in de markt maar de maturiteit van de (technische en niet technische) oplossingen is nog verre van voldoende. Is er ook ingegaan op de risico's en de voorwaarden waarop je federation wel kunt toepassen?
Nee zaken waar wij mee bezig zijn voor MP4U, MP4C en MP4A waren dus het onderwerp zeg maar. Maar dit werd alleen meer technisch benaderd en niet vanuit contractuele afspraken e.d. Dit soort zaken zijn lastig en moet je aan de juristen overlaten. Heb wel wat url's gekregen van een Australier waar allerlei voorbeeld contracten te vinden zijn. In australie zijn ze op dat gebied iets verder omdat het vanuit de regering gedreven is
Ik ben erg benieuwd naar die linkjes. Ik kijk er naar uit om daar eens tussen te gaan struinen :)
Een reactie posten