Sounds good. Thank you. On Wed, Sep 15, 2021 at 2:19 PM Robert <[email protected]> wrote: > > > Just fixed everything in my Overlay. Will open a PR tommorow. > > I just found out, that releasing the eduPersonTargetedID as NameID Attribute > is also not in AbstractSamlObjectBuilder#newAttributeValue. I have added a > quicktype checking for NameIDType and casting value to it, which produces a > correctly released eduPersonTargetedID attribute (which is built dynamically > via GroovyScript as complex object in our AttributeReleasePolicy). > > <saml2:Attribute FriendlyName="eduPersonTargetedID" > Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" > NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> > <saml2:NameID > Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" > NameQualifier="https://idp.example.com/cas/idp"; > SPNameQualifier="https://sp.example.com/shibboleth";>ESBrx6RqAIgLu46cUDIMzHf/5+Q=</saml2:NameID> > </saml2:Attribute> > > I will attach this fix to, tho it is mandatory to exclude this attribute from > consent policy, because XML Marshaller throws StackOverflowError, because of > self "owner" Property of NameID which points to itsself. > Maybe you find a smarter way to attach NameID subject as attribute. > > See > https://wiki.geant.org/display/eduGAIN/IDP+Attribute+Profile+and+Recommended+Attributes#IDPAttributeProfileandRecommendedAttributes-HowtotestthereleaseoftherecommendedattributestotheExampleServiceProvider > Misagh Moayyed schrieb am Dienstag, 14. September 2021 um 15:21:48 UTC+2: >> >> No problem. If you look at `SamlProfileSamlAssertionBuilder`, you'll >> find how to resolve the entity ID, in case the SP overrides for IDP >> metadata. For delegation, the entity id is always that of CAS resolved >> the same way, since CAS is the primary IDP to the SP anyway. The fact >> that an external IDP was used to authenticate is not relevant in that >> context. >> >> On Tue, Sep 14, 2021 at 5:18 PM Robert <[email protected]> wrote: >> > >> > Thanks for your fast answer. I will have a look, on how to fix it for >> > persistent NameIdFormat. >> > >> > My question was: What would be the correct unique identifier (entityId) in >> > case of delegated authentication? >> > >> > >> > Misagh Moayyed schrieb am Dienstag, 14. September 2021 um 15:08:41 UTC+2: >> >> >> >> > In all of my testcases the NameQualifier was set to the issuer of the >> >> > AuthnRequest, which is the SP. >> >> > Thats why the Shibboleth SP ignores the subject ID. >> >> >> >> Judging by the spec, at least for "persistent" identifiers, >> >> >> >> > In the case of an identifier with a Format of >> >> > urn:oasis:names:tc:SAML:2.0:nameidformat:persistent, the NameQualifier >> >> > attribute MUST contain the unique identifier of the identity provider >> >> > that created the identifier. >> >> >> >> So yes, this seems wrong. >> >> >> >> > My quickfix would be the use the entityId of the IdP, but that will not >> >> > handle relying IdPs. >> >> >> >> Don't follow the last bit. What do you mean "relying IdPs"? >> >> >> >> You'll need to account for entity ID overrides as well on per a SP >> >> basis; may or may not be that quick. >> >> >> >> > Is it a bug? Should I open a PR? >> >> >> >> Sure.
-- You received this message because you are subscribed to the Google Groups "CAS Developer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAGSBKkfDXOAoWEVFgkQJJAnpyxd3MLRxDVburUTFcPtXmMOe%3Dg%40mail.gmail.com.
