Integration with a Simitive SP

[Todd, James]

Hi Chris

Thanks. We might not need it now, they've found the UID attribute I'm sending in the attribute statement and are trying to use that instead of the Subject statement. If they can do that then I don't have to force round pegs in square holes, hopefully.

cheers
James
________________________________________
From: users [users-bounces at shibboleth.net] on behalf of Chris Reeves [chris.reeves at york.ac.uk]
Sent: 13 September 2016 18:02
To: Shib Users
Subject: Re: Integration with a Simitive SP

On Tue 13 Sep 2016 at 16:29:02 +0100, Todd, James wrote:
>
> Just a follow up to this, you say they wanted a subject nameid - am I
> correct in thinking they essentially wanted your staff Usernames or HR
> numbers transmitted as the SAML Subject? And with a format of
> urn:oasis:names:tc:SAML:2.0:nameid-format:persistent? We're past our
> encryption problems but now we're at problems with matching up what we're
> transmitting with what they're expecting.

Hi James,

We send them username using the (made up) format
urn:oasis:names:tc:SAML:1.1:nameid-format:userName. We shouldn't have done
this as it is invalid (not our namespace!) and in hindsight we should have
used something like urn:oid:0.9.2342.19200300.100.1.1 instead.

In v3 the config for this (in saml-nameid.xml) is:
        <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
            p:format="urn:oid:0.9.2342.19200300.100.1.1"
            p:attributeSourceIds="#{ {'usernameNameId'} }" />
where usernameNameId is an attribute containing our username, but this is not
much use to you as IIRC you're using Ping for your IdP...

> I was originally transmitting a computed persistentID under format
> urn:oasis:names:tc:SAML:2.0:nameid-format:persistent as the SAML Subject,
> then sending the userID as another attribute, as I do for other SPs who need
> the Windows Username, but it turns out they're trying to match the SAML
> Subject I'm transmitting with the UID they've had synced separately from our
> staff database which of course doesn't match up. The only way I can probably

Yes, they match whatever is in the Subject NameID with whatever you have told
them is the identifier in your data feed.

> release the UserID as the SAML subject is probably with a nameid format of
> urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified. However they sent me
> a copy of their attribute-map.xml which doesn't seem to have this nameid
> format present.
>
> I've told them they should either get the Username out of the attribute
> statement rather than the subject statement like every other SP we deal with
> or add urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified to their
> attribute-map if they must have a username as the SAML Subject. I cannot
> send a username with a persistent name format, my IdP wouldn't allow it. Nor
> would I want to anyway, given the OASIS spec for SAML2.
>
> I'm curious, though - as we're not the first Uni to deal with them: did
> anyone else "break" the SAML spec to work with them and send them a username
> as a persistentID, or did you force them to work under the SAML spec? It
> might be easier if I can get them to look at the config for another Uni they
> deal with and copy that, but only if nobody else bent their IdP out of shape
> to fit what they need...

We don't send them urn:oasis:names:tc:SAML:2.0:nameid-format:persistent, but
we did 'make up' another format which certainly did break the SAML spec
(because we made a bad decision to use their namespace). If we had used
urn:oid:0.9.2342.19200300.100.1.1 instead that may not have broken the spec
(or broke it less badly, because it's a valid URI), but I'm sure Scott can
clarify that...

Do you have the option of configuring another NameID format in your IdP using
a different URI? I tend to avoid using
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified.

Regards,
    Chris

> -----Original Message-----
> From: Chris Reeves
> Sent: 07 September 2016 15:59
>
> On Wed 07 Sep 2016 at 15:00:05 +0100, Cantor, Scott wrote:
> > On 9/7/16, 9:57 AM, Todd, James wrote:
> > >
> > > Thanks, Scott. I know I answered my own questions but when a vendor
> > > who has dealt with integration with other Universities threw this at
> > > me, then told me to read the Shibboleth documentation I really started
> > > to doubt myself or my own sanity. Sanity restored.
> >
> > Certainly makes you wonder what the other universities did.
>
> Our integration with Simitive was quite painful (our instance was the most
> recent Simitive SP to be added to the UK Federation). They asked for our
> entityId and an attribute to release as a unique ID (they actually wanted a
> Subject NameID). We gave them that and pointed them at the UK Federation
> metadata for anything else they needed.
>
> Once they had registered with the federation the configuration on our side
> was quite straightforward and didn't need much further modification (other
> than having to release an additional attribute that they don't actually
> use). Things didn't go quite so smoothly on their side though, and in the
> end they had to call in consultants to get the SP working. :-S
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
This message and its attachment(s) are intended for the addressee(s) only and should not be read, copied, disclosed, forwarded or relied upon by any person other than the intended addressee(s) without the permission of the sender. If you are not the intended addressee you must not take any action based on this message and its attachment(s) nor must you copy or show them to anyone. Please respond to the sender and ensure that this message and its attachment(s) are deleted.

It is your responsibility to ensure that this message and its attachment(s) are scanned for viruses or other defects. Edinburgh Napier University does not accept liability for any loss or damage which may result from this message or its attachment(s), or for errors or omissions arising after it was sent. Email is not a secure medium. Emails entering Edinburgh Napier University's system are subject to routine monitoring and filtering by Edinburgh Napier University.

Edinburgh Napier University is a registered Scottish charity. Registration number SC018373