Post saml reponse from one shib idp to other shib idp

[David Huebner]

On 16.05.2018 16:06, Peter Schober wrote:
> * David Huebner <david.huebner at daasi.de> [2018-05-16 15:37]:
>> The only possible advantage of doing that inside the SAML proxy is
>> user friendliness. That way the user does not have to enter his
>> credentials (i.e.  email) twice.
> I thought asking for email was only done to get the subject to type
> the DNS domain of their IDP (i.e., it's only about phrasing this in a
> way that the subject should be able to understand, not about the
> user-identifying part and certainly not about entering the password in
> more than one place?
>
> I.e., the purpose of this process seems to be to replace
> typeahead-style UI components (to interactively determine the IDP
> based on some identifying information, could be display name, parts of
> the entityID, etc.) with "type your DNS domain and hit enter", and
> then either failing that with an error ("Cannot find the IDP") or
> start the SAML2 login flow to the IDP, hopefully the one the subject
> intended.
> Only there would I enter my identifying information ("credentials").
>
> -peter
 From what I understood the purpose is not only to identify the IdP to 
be used for authentication (discovery service), but actually 
authenticate the user straight away (and by that I mean ask the user for 
his password) if certain conditions are met (i.e. the DNS domain of the 
email address entered matches some preconfigured string).

Let's assume that preconfigured string is example.org. The "primary IdP" 
would then go ahead and present the user with a form "Please enter your 
email address".

Case 1: User enters john.d at example.org. Primary IdP says "Oh, 
example.org is my domain and I can authenticate that user against my AD" 
and asks for password.

Case 2: User enters john.d at someotherdomain.org. Primary IdP says "I 
don't recognize that domain" and sends the user off to the "Secondary 
IdP" via its SP component (or then presents the user with a discovery 
service).

In the end the idea is, that *most* users are in fact Case 1 and should 
not be annoyed with the extra discovery service before getting to the 
"Primary IdP" (neglecting permanent cookies for now).

- David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2269 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://shibboleth.net/pipermail/users/attachments/20180516/e7048579/attachment.p7s>