> you're using SAML 1
Yes, there's no requirement to use SAML2 so we haven't moved as it would
likely prove problematical to personalisations. Our metadata doesn't
expose any SAML2 endpoints so why would they be expecting attributes
associated with SAML2 profiles? Our IdP supports SAML2 Web Browser SSO and
the associated attributes but it's not advertised as that would mean all
other SPs switching to SAML2 and possibly losing our personalisations.
-------------------
Alistair Young
Àrd Innleadair air Bathair-bog
UHI@Sabhal Mòr Ostaig
On 05/12/2012 12:30, "Ian Young" <[log in to unmask]> wrote:
>
>On 5 Dec 2012, at 11:59, Alistair Young <[log in to unmask]> wrote:
>
>> There's no persistent_id listed after logging in. Only affiliation and
>> targeted_id
>
>Sounds like
>
>(a) you're using SAML 1
>(b) you're sending the urn:mace:Š form of ePTID, presented to them as
>targeted_id
>(c) they are relying on the urn:oid:Š form with the SAML 2 NameID inside,
>which the default configuration presents to them as persistent_id
>
>For the avoidance of doubt, I'm talking about the one that looks like
>this on the wire (in SAML 1):
>
><saml1:Attribute AttributeName="urn:oid:1.3.6.1.4.1.5923.1.1.1.10"
>AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
> <saml1:AttributeValue>
> <saml2:NameID xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
>Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
>NameQualifier="https://idp2.iay.org.uk/idp/shibboleth"
>SPNameQualifier="https://test.ukfederation.org.uk/entity">JvrX5ug6gCfjaOUR
>KcE5kYpqLK0=</saml2:NameID>
> </saml1:AttributeValue>
></saml1:Attribute>
>
>If your IdP can release the newer form instead of or as well as the older
>one to this SP, that's probably the simplest solution. You're still
>running a Guanxi IdP, I think (perhaps I should say *the* Guanxi IdP) and
>I don't know whether it can do that.
>
> -- Ian
>
>
>
|