[prev in list] [next in list] [prev in thread] [next in thread] 

List:       shibboleth-users
Subject:    Re: persistant nameid conflicting requirements
From:       "Youssef  GHORBAL" <youssef.ghorbal () pasteur ! fr>
Date:       2016-03-29 21:56:58
Message-ID: 8F4BC49A-193D-425A-9190-EFF0897CAEEC () pasteur ! fr
[Download RAW message or body]


> On 29 Mar 2016, at 21:13, Cantor, Scott <cantor.2@osu.edu> wrote:
> 
> > 	IdP 3.2.1 and persistant nameid generation conflicting requirement.
> > 	I have a silly SP that needs a persistant nameid format but with the
> > account uid in the value.
> 
> And you know this because? In most cases they are wrong about it anyway or can be \
> pressured into doing it correctly. Make them deal with the one-off.

Because I set it up in the current running 2.4 instance.
I tried back then to make them handled it differently in vain.
They don't care about any other attribute, all they do is get the info from the \
NameID and query it over LDAP to have the rest of the information (names, titles etc) \
=> A random number will not work here since the hash does not end up in LDAP.

You know this kinda a situation when the Big Editor pretends to have SAML support and \
your campany tries to make it work with a subcontractor that does not have the \
slightest idea what SAML is… You try to work something out and you end up doing \
this kind of atrocities. SAML is the top of the iceberg, they require Redhat \
Entreprise Linux and don't understand that CentOS is the same thing (at least for \
their use case) they require a strict partition schema for the disk. They open a \
single LDAP connection (without any heartbeat or pooling management) that end up \
blocked by the firewall (after hours of inactivity) etc etc.

I think that in recent versions that support emailAdress type nameid, I'll try to \
push it that way, but at least I have this backup solution.


> > Can I configure an override for that particular SP that generates a
> > nameid with a custom persistant value ?
> 
> Yes, but you shouldn't and I very much doubt you have to. If you do, you should \
> identify the vendor so people know about the issue.

It's an ECM (Electronic Content Management) solution by the name of xECM by OpenTEXT \
editor.

> > 	But IdP is still sending the calculated persistent nameid.
> 
> What you posted appears to be correct, assuming you put it in the appropriate \
> order.

That did the trick, I was not aware that the order matters. And thank you again for \
you availibility and your assistance.

Youssef
-- 
To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net


[prev in list] [next in list] [prev in thread] [next in thread]