Hi Peter,
SAML is not an ideology, it’s a specific set of messages and bindings used in profiles, which are basically what you would call a protocol. Obviously, you can’t modify how the protocol works, and the protocol does not contemplate any use case like the one you are depicting.
Now, SAML responses are always sent in response to a SAML request (with some exceptions, like IdP-initiated authentication, when an IdP sends a SAML response to an SP without a previous request). What you are suggesting is sending a SAML response in response to another SAML response, which is not supported.
You have two ways forward, and none of them implies getting back control at your IdP during authentication:
- One option is to do automatic provisioning to those problematic SPs. You can just have a cron job every night or something like that, going through the list of users in your IdP, and telling the SPs: “here’s the list of my users, please create accounts for those users missing in your system”. Of course, the SP must have some mechanism to allow for this.
- The other option is what most SPs do: dynamic provisioning, meaning when a SAML response with an assertion arrives at the SP and the user is unknown because there’s no associated local account, the SP will just create the account on the fly, instead of showing an error.
In any case, as you can see the SP needs to deal with the problem somehow, and you definitely can’t modify the SAML protocol to your will.
--
Jaime Pérez
UNINETT / Feide
jaime...@uninett.no
jaime...@protonmail.com
9A08 EA20 E062 70B4 616B 43E3 562A FE3A 6293 62C2
"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost