Thanks for all the responses to this. To me, the fact that every university has a different SP entry configured in ALMA means it makes little difference whether it's published in the federation metadata - I can't just access it as if it were another partner resource provider. Compared with some other providers, I've found ExLibris more difficult to deal with, though once I was pointed to the right person, they sorted out the problems we were getting quite quickly
From: Discussion list for Shibboleth developments [mailto:[log in to unmask]] On Behalf Of Peter Schober
Sent: 01 March 2018 17:04
To: [log in to unmask]
Subject: Re: [JISC-SHIBBOLETH] ALMA
* Sue Stevens <[log in to unmask]> [2018-03-01 14:16]:
> You need to setup a SAML integration profile in Alma with your IdP settings and a certificate. Details here:
So does that mean nothing happens via the federation (ALMA needs to be
spoon-fed every single IDP by $someone; and every single IDP needs to
add an IDP-specific logical SP for ALMA on their side) or that some
parts of that can use the existing published metadata?
(Any why oh why didn't the global community of ExLibris customers
throw up their arms about this "IDP-specific SP instance" nonsense
while there was still time? "Just say no!")
Looking at the above document:
* Does anyone know what the effect of checking vs. not checking the
"Default SAML Profile" checkbox are?
* When loading the IDP metadata from a URL or file, what will be
picked as the "User ID location" and "User ID attribute name"?
* Do I read the screenshot correctly that their metadata is signed
with an expiration date of 1.5 years into the future? So open to
replay attacks on the one hand (you can feed an IDP old metadata for
1.5 years) but still metadata needs to be (likely manually) updated
for thousands of institutions every 1.5 years?
OTOH their example metadata
is not signed at all. And the certificate it contains is self-signed.
So no security whatsoever...
Their section "Define the match point of user data" has examples of
Attributes using the URI nameformat but with non-URI (i.e., basic)
attribute names, also invalid.
But then you can't seem to pick the NameFormat to use for attribute
names... nor the NameID format you want.
They show a NameID element with a Format of
"urn:oasis:names:tc:SAML:2.0:nameidformat:uri", which is two errors in
one, as there's no such URI defined by OASIS (missing dash between
"nameid.format") and also there are no URI-format for NameIDs (what
exists are transient or persistent).
The whole XML shown in that section isn't even well-formed (missing
whitespace before XML attributes)...
Their other examples
also contain those invalid SAML namespaces
So this all looks really, really, bad...
This email has been scanned for spam & viruses. If you believe this email should have been stopped by our filters, click the following link to report it (https://portal.mailanyone.net/index.html#/outer/reportspam?token=dXNlcj1NYXguQ2FpbmVzQFdMVi5BQy5VSzt0cz0xNTE5OTIzOTQ0O3V1aWQ9NUE5ODMyRTgyNjczNjg4RTdDMzg3NDY1NkE4OEM1RDg7dG9rZW49MWYzOTNiMWYwNzRjYTMyOTI2NzgyZDIwNDk1ZjVjNzQyNjM3Yzc1Njs%3D).