565
szerkesztés
Módosítások
→Problémák
== Shibboleth SP Metadata importálása OpenSSO-ba ==
A lementett XML-ből töröljük ki az <md:Extension> node-ot, mivel a parszolás során hibaüzenetet dob, ami a teljes SAML2Meta konfigurációt megfekteti. ERROR: SAML2MetaManager.getEntityDescriptor javax.xml.bind.UnmarshalException: Unexpected end of element {urn:oasis:names:tc:SAML:2.0:metadata}:Extensions ... Ha ez a hiba előjön, akkor a konfigurációs címtárból kell törölni az entity-t, ugyanis ilyenkor teljesen használhatatlan lesz a felület (ez egy bug sajnos) $ ldapmodify ... dn: ou=<entityid>,ou=default,ou=OrganizationConfig,ou=1.0,ou=sunFMSAML2MetadataService,ou=services, o=<realm>,ou=services,<basedn> changetype: delete A problémát az okozza, hogy amikor a metadata xml-t beolvassa a SAX parszer, akkor JAXB-vel mappeli java objektumokra, és ezt marshallolja ki a konfigurációs store-ba. Viszont az Extensions belseje egy teljesenkülön névtér és külön séma, ezért arra nincsenek generált osztályok. Ezt úgy veszi a JAXB, hogy egy <Extensions/> -t ír ki, ami viszont unmarshal időben nem felel meg már a sémának (ugyanis xsd szerint ott legalább egy elemnek lennie kell). Egyelőre azt a megoldást javasolták, hogy kézzel szedjem ki az <Extensions> -t, aminek továbbra sem örülök az xml aláírás és a kézi hegesztés miatt. Idővel egy olyan javítást fognak készíteni, amivel user osztálykönyvtárat meg lehet adni az opensso-nak, hogy a metaadat bizonyos részeit (pl. extensions belseje) arra mappelje le. Illetvetettem egy olyan javaslatot, hogy ilyen esetben amikor kinullozza a node belsejét a JAXB, akkor a teljes <Extensions> node-ot töröljék, így legalább az xml valid marad. Talán azt is javítják, hogy ilyenkor a teljes metaadat rész összeomlik és semmilyen műveletet nem lehet végezni. (https://opensso.dev.java.net/issues/show_bug.cgi?id=2736) A ManageNameIDService ill. AssertionConsumerService közé írjuk be a következő node-otokat:
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
Ha nem adunk meg NameIDFormat -ot, akkor az OpenSSO IdP vissza fogja utasítani a kérést. Megj. https://opensso.dev.java.net/issues/show_bug.cgi?id=2172 hosszútávon ezt a viselkedést valószínű megváltoztatják.
Ezt a metaadatot a Federation fül Entities -> Import Entity parancssal tudjuk importálni. Itt ki kell választani a /niif-teszt realm-et, és feltölteni az XML-t (vagy megadni az URL-jét). Ezután felül a Circle of Trust-nál hozzá tudjuk már adni a SAML2 SP-t.
Ha mindezt végigcsináltuk, máris működik minden.
== Problémák ==
Ha Shibboleth2 SP-ben külön application-be tesszük a metaadatot, akkor nem találja meg a SAML Response issuer-alapján.
Az attribute-mapOpenSSO nem jelzi a saml attribútum névformátumát (<saml:Attribute NameFormat="...">).xml -ben hiába mappelek egy attribútumot, nem találja meg A Shibboleth pedig csak az attribute push-banurn:oasis:names:tc:SAML:2. (az unspecifiedd 0:attrname-et nem én írtam be format:))uri típusú nevet fogadja el.
shibd.log:
2008-05-14 18:33:31 INFO Shibboleth.AttributeExtractor [1]: skipping unmapped SAML 2.0 Attribute
with Name: urn:mace:dir:attribute-def:mail, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:unspecifiedd
Itt egy patch OpenSSO-hoz ami megoldja a problémát: https://opensso.dev.java.net/issues/show_bug.cgi?id=2775
Ezen patch használatával a következő módon kell megadni az IDP attribútum mappelést az IDP > Attribute Processing fülön:
# [NameFormat|]SAMLAttributeName=LocalAttributeName
urn:oasis:names:tc:SAML:2.0:attrname-format:uri|urn:mace:dir:attribute-def:mail=mail
