Solicited and Unsolicited

[Lohr, Donald]

Without disclosing too much.

Let's say one of our departments wants to develop a webpage that will 
function as a landing page to list applications that their employees and 
students most frequently login to.

Let's also say the "powers to be" want this landing page accessible via 
only an LDAP auth.

Let's also say that most of the applications earmarked for this landing 
page are off-prem applications that are already existing accessible via 
our Shibboleth IdP.

The conversation was to not have a dual login scenario where the users 
are required to LDAP auth to access the landing page then login again at 
our IdP login page.  The question was asked, could we send something to 
the IdP that indicates the user has already logged into a "trusted" 
system, and act like they did an IdP auth and still pass a SAML response 
to the said SP that they chose off that original landing page.

Not saying this is a good approach, I've just been charged with 
information gathering.

I will also look at the SAML ECP that was mentioned.

Thanks,
D

On 4/3/19 12:49 PM, Lohr, Donald wrote:
> We currently have 3 SP's that support two auth models that I will 
> refer to as "Solicited" and "Unsolicited".
>
> Solicited: Using the SP url, user is redirected to our IdP federated 
> login page where our user would enter their loginID and password.
>
> Unsolicited: Our users can login to another (on-prem) application, 
> click a link and "leap-frog" (if you will) to one of these three SPs 
> using an encrypted secret (which is an agreed SAML response).
>
> My questions:
>
> Say we have an application that only does LDAP auth (like a portal of 
> sorts that does not use our IdP).  Is it possible for that application 
> to send an unsolicited SAML response to our Shibboleth IdP (an agreed 
> to response) that could be processed by the IdP as if the user did the 
> normal solicited login?  At which point, could the normal "flow" (if 
> you will) happen: 1) the user's loginID would be looked up in the LDAP 
> directory for the required attributes 2) processed by the filter & 
> replying party configuration 3) a normal SAML response generated 4) 
> the user redirected to the said SP?
>
> thx,
> D
>