SWAMID stödjer officiellt Shibboleth Identity Provider och Microsoft Active Directory Services (ADFS) via ADFS Toolkit. För mer information se SAML IdP Best Current Practice.
SWAMID har idag inte stöd för OpenID Connect Federation men planerar att få det när den standarden är färdig. Fram tills dess går det endast att koppla en OpenID Connect Relaying Party till SWAMID via en proxy som översätter protokollet OpenID Connect till SAML2 WebSSO. Två exempel på sådan proxy är Satosa och SimpleSAMLphp.
Jovisst men då tappar man möjligheten att kommunicera mellan organisationer. Dessa teknologier har sin plats som SSO-lösningar inom en organisation och fungerar bra som login-lösningar för shibboleth men om man vill skicka attribut mellan organisationer eller undvika att göra sin applikation beroende av någon specifik användardatabas (tex LDAP) så är en SAML-baserad identitetsfederation enda praktiska alternativet idag.
Nej. Shibboleth och ADFS kan fungera som SSO-lösning inom en organisation helt enkelt genom att man sätter upp en intern federation.
En federation är i princip bara en metadatafil som hålls synkroniserad mellan alla medlemmar. Skapa och underhåll en metadatafil och sätt upp en discovery-tjänst någonstans så är du igång. Det är rekommenderat att lagra certifikat i metadatafilen (jämför hur swamids metadata ser ut) istället för externt eftersom man då undviker många problem med certifikatvalidering.
Gå till Release check for SWAMID och prova de olika testerna. Om allt fungerar så ska du åtminstone se din identitet i eppn-fältet. Beroende på vilka attribut som din IdP släpper ut så ser du även andra fält.
Scope är ett shibboleth-begrepp som betyder 'administrativ domän'. Vissa attribut som skickas från en IdP till en SP har ett scope som anger vilken domän/organisation som utfärdat värdet. Ett exempel på användningen av scope är attributet eduPersonPrincipalName som ofta mappas till användaridentiteter i IdP:n. För att det inte ska bli kollision mellan identiteter mellan olika organisationer används scoping. I SAML representeras scope som ett attribut på <AttributeValue/>-element men scope visas ofta med @-notation som tex nissehult@example.com - där example.com är scope. I detta exempel är nissehult användarnamnet på en användare från en IdP som har scope example.com (kanske heter idp:n https://idp.example.com/identity men det är långt ifrån säkert).
När en SP tar emot attribut med scope så kan SP:n filtrera baserat på scope (tex för att bara tillåta användare från organisationer SP:n har kontrakt med). Exempelvis kan ett SAML-response för nissehult innehålla följande (exemplet är baserat på SAML1 men för SAML2 ser det ungefär likadant ut):
<Attribute AttributeName="urn:mace:dir:attribute-def:eduPersonPrincipalName" AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"> <AttributeValue Scope="example.com">nissehult</AttributeValue> </Attribute> |
Tekniskt är en federation bara en metadatafil som hålls synkroniserad mellan alla entiteter (SP och IdP) som ingår i federationen. Både SP:n och IdP:n stödjer att man pekar ut flera olika metadatafiler.
Detta styrs genom sk "attribute release policy". I default-installationen av shibboleth 1.x finns det i filen idp.xml ett <ReleasePolicyEngine>-element som innehåller konfiguration av en fil-baserad attribute-policy-motor. Denna använder xml-filer som lagras på IdP:n. Filen site.arp.xml innehåller inställningar som gäller för alla användare. Dessutom kan man ha filer för individuella användare. I normalfallet så är det SP:n och IdP:n som kommer överens om vilka attribut som ska skickas men det kan vara intressant att låta användaren få kontroll över vissa detaljer. Inom SWAMID Har vi infört en skalbar modell kalalt entitetskategorier för att förenkla på ett personuppgiftsvänligt sätt konfiguration av attribut, se Entity Categories for Service Providers för mer information.
Attribut från IdP:n exponeras i SP:n som HTTP request headers. I java (tex) kan man komma åt dom med HttpServletRequest#getHeader. Namnet på headern styrs av SP-konfigurationsfilen AAP.xml. Ett specialfall är eduPersonPrincipalName som normalt exponeras som REMOTE_USER (dvs HttpServletRequest#getRemoteUser i java). För mer information se SAML SP Best Current Practice.
Attributet är flervärt. Värden separeras med ';'.
Certifikat används på två ställen: dels för att skydda kommunikationen mellan användaren och IdP:n (resp SP:n) och dels för att skydda transporten av attribut mellan IdP:n och SP:n. För skydd av kommunikation mellan användaren och webbapplikationerna som vänder sig till användare (tex IdP:ns inloggningsdel eller en webapplikation som använder shibboleth för authenticering) kan man använda vilket certifikat som helst. Det finns ingen policy som styr valet - swupki eller kommerciella certifikat går lika bra.
För kommunikationen mellan IdP och SP används i SWAMID certifikat som publiceras i metadata för federationen. Dessa kan vara självsignerade eller vanliga certifikat men valideringen av dessa certifikat sker genom att de jämförs med certifikatet i metadata och inte baserat på hela kedjan upp till ett trustankare. Det betyder att man kan använda vilket certifikat som helst, även det vanliga tls certifikatet
eduGAIN är en interfederation av akademiska federationer runt om i världen. SWAMID är medlem i eduGAIN och det gör att användare från SWAMID kan logga in i tjänster i andra federationer och användare i andra federationer kan logga in i tjänster i SWAMID.