Integration with a Simitive SP

[Chris Reeves]

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