SharePoint 2010, ADFS ja claims

Postitatud: 4. juuli 2012 | Autor: | Filed under: tarkvara | Tags: , , | 1 kommentaar

Ehk siis mida tarka ma õppisin TechEd Europe 2012 eelseminarilt PRC01  Building Federated External Access for Microsoft SharePoint 2010 (John Craddock):

  • Claims ja Federation – mingi Identity Provider (IP) annab meie rakendusele info kasutaja kohta, autentimine toimub tema juures, vastu saame Security Tokeni (ST). Usaldus on kahepoolne, st STS usaldab rakendust, rakendus usaldab STSi (kaks sertifikaati). STSina saab kasutada ka näiteks Facebooki, LiveID, Google jms.

Claims ja Federation suhtlus (John Craddock, http://blog.xtseminars.co.uk/what-is-federated-identity-and-authorization)

  • Autoriseerimine toimub rakenduses vastavalt saadud claimile. Kõik  Security Token Providerid (STS) saavad ise claime ümber kirjutada vastavalt vajadustele (nt lisada teatud IP (mitte segi ajada IPga) kaudu autenditud kasutajatele kindel roll). Seal saab kasutada ka muid andmeallikaid (Attribute Stores), milleks võib olla AD, LDAP, SQL või muu taoline andmebaas. Kui me lisame SPle Custom Claims Provideri, toimib ka tema nagu STS.
  • ADFS – konfigureerimine läbi PowerShelli (PS).  SPTrustedIdentityTokenIssuer tuleb luua, et saaks vastavat STSi valida. Ühel Web Applicationil võib olla mitu STSi ja üks STS võib olla mitmel Web Applicationil.
  • Claimide lugemine: tegelikult on Claim objekt, millel on tüüp, väärtuse tüüp, väljaandja ja väärtus. SP konverteerib need stringideks:

John Craddock, XTSeminars

Home Realm Discovery (kaks valikut)

  • SP teeb kasutajatel vahet sõltuvalt sellest, mis STS kaudu nad ennast autendivad (nt sama kasutaja otse AD või AD läbi ADFS autentides on erineva kasutaja). Võib põhjustada segadusi, seega on targem jätta ainult üks variant.
  • Küpsised! ADFS küpsised (4 erinevat http://blogs.technet.com/b/geoffrey_carlisle_on_idm__security/archive/2010/10/13/common-adfs-cookies.aspx) ja SP Web Application küpsised (FedAuth). SP küpsised peavad olema persistent (st mitte-sessioonipõhised), kui tahetakse kasutada Office’it. Ühtlasi peab olema sait ka brauseri arvates trusted. Vaikimisi  on FedAuth kestus (TokenLifeTime) 60 min (kuigi kirjas on 0). Ühesõnaga, erinevad küpsised vaatavad, kas kasutaja on autentitud SP mõttes ja STS mõttes. Seadistus sõltub olukorrast ja turvakaalutlustest. Võimalus on ka sliding sessions.

Küpsised, John Craddock, XTSeminars.co.uk

  • Väljalogimine – millest me välja logime, ainult SP või ka STS? Mõistlik on välja logida ka STSist. OOTB SharePoint seda ei tee, vaja kirjutada koodi (tekitada eraldi leht). Omaette teema on ADFSist välja logimine – tuleb välja logida ka kõigist WA või muudest asjadest.
  • Claims Augmentation (claimide ümberkirjutamine, suurendamine, transformeerimine?) – kõige mõistlikum on claime hallata AD FSis: grupeerimine, metaclaims ja claims store
  • User Identity Store – kust me saame infot kasutajate kohta (nt SP profiili jaoks)? Kasutaja info import, andmete võtmine claimist (aga seal ei pruugi just palju olla), eraldi andmete kogumine (nö registreerumine)
  • UAG? http://www.microsoft.com/en-us/server-cloud/forefront/unified-access-gateway.aspx
  • ADFS deploy – kui me ei luba enam Windowsi autentimist on ainus viis, kuidas rakendustele ligi saada = kriitiline komponent. Alati farm, saab laiendada, dubleerida jne. Proxyd, tulemüürid…
  • Üldiselt hakkabki elu nii käima, vaja on väga mitme osapoole koostööd – arendajad, IT, konsultandid jpt

TL,DR – jah, SharePoint, claims ja ADFS töötavad ka OOTB, aga vähegi viisakama kasutuskogemuse jaoks on vaja arendajatel ka tööd teha.

Lingid:

Kes rohkem kuulda tahab, mis seminaril näidati või räägiti, võib minuga ühendust võtta.

Muidu – oli väga hariv ja silmi avav päev. Nii mõnigi “ahhaa-koht” tuli ette ja ütleme nii, et oleks kõike seda sügisel teadnud, oleks hulka aega ja närve ilmselt kokku hoidnud. Aga parem nüüd kui mittekunagi. Igal juhul suur tänu John Craddockile meeldejääva päeva eest ja mõni teine kord jälle.