Hur får jag in min IdP i listan på

...

swamid.se

...

?

Listan på IdP:er/organisationer på wayfmd.swami.se eller ds.swamid.se utgörs nordu.net utgörs av de organisationer som är medlemmar i SWAMID samt organisationer som SWAMID har avtal med. För att synas måste förutom medlemskap krävs det att organisationen har skickat information om sin IdP till operations@swamid.se. Inkludera namnet på IdP:n (tex https://idp.example.com/identity) samt det certifikat som används för att skydda attribut-release, vanligen specat i idp.xml. Om din organisation inte är medlem i SWAMID finns information om hur ni blir det på http://www.swamid.se/11/policy/swamid-2.0.html.

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.

...

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

• SAML - protokollet som bär information om användare och attribut inom en federation.

• OAuth - ett protokoll för delegering av behörigheter mellan applikationer.

• OpenID - Används för att autenticera slutanvändare, dvs kan ses som en "personlig" IdP.
• OpenID Connect - Nästa generations protocol, ibland kallat "SAML 3".

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 wayfdiscovery-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ällt för externt eftersom man då undviker många problem med certifikatvalidering.

...

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>

...

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

Jag får inga attribut från min IdP när jag går via wayf.swamid.se

Tjänsten wayf.swamid.se är Shibboleth 1-baserad idag som initierar en SAML1-inloggning. För att attribut-release ska fungera krävs att din IdP stödjer SOAP-baserad attribut-release. Läs mer här: https://spaces.internet2.edu/display/SHIB2/IdPApacheTomcatPrepare. Testa detta genom att gå till https://sp-test.swamid.se och gör en inloggning via dels "swamid" och dels via "swamid ny DS". Om du får attribut via den andra inloggningen men inte via den första så är det med stor sannolikhet fel på din IdPs SOAP-baserade attribute-authority (normalt på port 8443).

Varför ska jag bry mig om Kalmar Unionen?

...