Vilka Identity Provider programvaror har SWAMID stöd för?

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.

Kan man inte använda OpenID Connect (OIDC) istället?

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.

Vad är det för skillnad mellan SAML, OAuth och OpenID?

Kan man inte använda CAS eller någon annan Enterprise SSO istället?

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.

Behövs en SSO-lösning ändå?

Nej. Shibboleth och ADFS kan fungera som SSO-lösning inom en organisation helt enkelt genom att man sätter upp en intern federation.

Hur sätter jag 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.

Hur testar jag om min identitet fungerar?

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.

Vad betyder 'scope'?

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>

Kan en SP/IdP vara medlem i mer än en federation?

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.

Hur väljer jag vilka attribut som skickas?

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.

Hur använder jag attribut från en IdP?

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.

Det står ';'-tecken i attributvärden! Vad betyder detta?

Attributet är flervärt. Värden separeras med ';'.

Vilka certifikat behövs?

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

Varför ska jag bry mig om eduGAIN?

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.