Hello all,
Disclaimer: I'm the techie here, for whatever that's worth, rather than
the librarian ... This issue is a bit technical, I've tried to be brief.
However, if it rings any bells at other sites, and you can put me in touch
with someone who may also have dealt with these issues, then that would be
appreciated.
On behalf of my friendly local neighbourhood e-resources librarian Fiona
Tinto, I've been working through the requirements to add FitchConnect to
our Shibboleth IdP (v2.4, sorry). Fiona has told me I have to say this to
put this email into context: "this whole Fitch Connect SSO set up is in
relation to the migration from BMI Research to FitchConnect."
First of all, once we got their metadata, their entityId for their SP is
"com:fitchsolutions:api:sp". So my first "problem" is that on my
understanding, given that format is from neither approved
scheme/controlled namespace (https:// or urn:), this entityId is not
guaranteed to be globally unique, and is not valid.
Of course, when challenged: "To confirm our Our entityID
"com:fitchsolutions:api:sp" serves as an entity identifier. So far, all
SSO clients we have on-boarded have recognized our enityID. Unfortunately,
we can not change to URN"
Fine, whatever, we'll put up with it (like all those other SSO clients
have had to). I presume they wouldn't be allowed to join a federation
with that entityId, however.
So next issue. According to their SSO guide:
"Fitch currently only supports email address as the nameid in assertions
sent from the Identity Provider. Therefore, Single Sign-On with Fitch is
only possible if the Identity Provider is capable of sending assertions
with email. We are currently working on supporting more nameid formats
such as username. If you have a specific nameid format you would like
implemented, please contact Client Services."
and their metadata has:
<NameIdFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>
<NameIdFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
<NameIdFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
We have never had to provision for nameid-format:emailAddress. More
normally we'd expect to see something like:
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
(I admit NameIdFormats is skirting on the edges of my ignorance; never
really needed to pay attention to them before).
While I think I see how it would be done, I have misgivings about having
to do so for this one SP. We also then have the issue that we are
releasing personal data to them in the form of an email address, which we
would need to be able to justify. I'm tempted to just ignore this bit and
see what happens.
We've asked for a list of the attributes they require, since their
documentation doesn't seem to state anything, so I am none the wiser about
further privacy issues at this point.
Thanks for any advice or observations; if it turns out from this question
that we do implement the emailAddress name-id route, I can take the
specific questions to a more technical list.
Jethro.
. . . . . . . . . . . . . . . . . . . . . . . . .
Jethro R Binks, Network Manager,
Information Services Directorate, University Of Strathclyde, Glasgow, UK
The University of Strathclyde is a charitable body, registered in
Scotland, number SC015263.
lis-e-resources is a UKSG list - http://www.uksg.org
UKSG groups also available on Facebook and LinkedIn
Follow us on Twitter: https://twitter.com/UKSG
|