Passing login credentials directly to idp

[Salil Lambay]

I was able to setup the simplesaml with my application and also the authentication is working as expected. 

But now what i expect is the user need not see the login page (of idp) where he enters userid and password. I wish to pass the userid and password to idp directly.

How can this be achieved?

[Jaime Perez Crespo]

Hi Salil,

On 04 Sep 2016, at 23:01 PM, Salil Lambay <lambay...@gmail.com> wrote:
> I was able to setup the simplesaml with my application and also the authentication is working as expected.
> But now what i expect is the user need not see the login page (of idp) where he enters userid and password.

What’s the IdP here for then?

> I wish to pass the userid and password to idp directly.
> How can this be achieved?

The SAML protocol does not allow that, obviously, and neither does SimpleSAMLphp. I say obviously, because it seems pretty obvious that if you want to delegate authentication to a third party, that’s precisely to stop managing credentials. But apart from that, what you want to do is fundamentally wrong from a security perspective. Let me elaborate. If you force your users to type their username and passwords in your service just to forward them to the IdP right away, you are getting the credentials of a user that you are not supposed to have. It might be that you control also the IdP, but that doesn’t make it right anyway. If another service provider is connected to the IdP (which is the only reason I would imagine to delegate authentication to an IdP in the first place), how is it supposed to work then? Are you going to require the users to post their credentials there too? If you don’t control that SP, will you make your users then go to the login form of the IdP to authenticate? In any case, you would be asking your users to type their credentials in two different places. The implicit message you are sending them then is: “it’s ok that you type your credentials in different places”, and the consequence is that they will do type their credentials in different places, including phising pages where they’ll get their login and password stolen.

You just started to delegate authentication from your application to an external identity provider. Now, do it right. Stop pretending that the users give you their credentials any longer, and tell them instead to authenticate *only* in the IdP, if possible, verifying the URL.

--
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

[Steve Briggs]

Jaime - what then is the best way to create a seamless UI/UX experience for the user? We want the user to go to our application page (SP), click a Login button, and be taken to a login page (on the IdP I'm assuming) that looks just like the SP application. The domain and URL will obviously be different, but the look and navigation should be consistent with the application so that the user is not confused. I'm thinking I would create a page on the IdP specifically for my application that uses the application UI template, but that incorporates the username and password form from the SSP example. Is that correct? Is this how it's normally done? Are there any concerns to be aware of?

Also, in order to set up my application as an SP using the SSP API, since I'll need to set up a new instance of SSP within the application anyway, would I be better off using that installation as both the IdP and SP? Or is it better to keep the IdP separate from the SP?

[Jaime Perez Crespo]

Hi Steve!

On 05 Sep 2016, at 14:55 PM, Steve Briggs <st...@wowpages.com> wrote:
> Jaime - what then is the best way to create a seamless UI/UX experience for the user? We want the user to go to our application page (SP), click a Login button, and be taken to a login page (on the IdP I'm assuming) that looks just like the SP application. The domain and URL will obviously be different, but the look and navigation should be consistent with the application so that the user is not confused. I'm thinking I would create a page on the IdP specifically for my application that uses the application UI template, but that incorporates the username and password form from the SSP example. Is that correct? Is this how it's normally done? Are there any concerns to be aware of?
>
> Also, in order to set up my application as an SP using the SSP API, since I'll need to set up a new instance of SSP within the application anyway, would I be better off using that installation as both the IdP and SP? Or is it better to keep the IdP separate from the SP?

I think we should first answer a basic question: why do you need to use SimpleSAMLphp (or other SAML implementation)? The main purpose of SimpleSAMLphp (and others) is to enable applications (the service providers) to delegate authentication to a central point (the identity provider).

As you can imagine from that, the usual scenario is one single login form for an institution, say, University of Whatever, or Evil Corp. Inc. No matter what kind of organization it is, you will want one login page that is easy to identify and that’s recognizable by the users. You just can’t customize the appearance of the IdP to match the appearance of one SP, because if more than one SP uses the same IdP, it would look weird when you try to login to the second application and the login form looks like you are in the first one.

If you just want to authenticate users to given them access to *one* application, using SAML (it doesn’t matter if it’s SimpleSAMLphp or some other library) is a bit of an overkill. On the contrary, if you really want single sign on across domains and different applications, then it doesn’t make sense to customize the IdP to look like one of them. Customize it to look like your organizational login form, brand it and make sure people gets familiar to it. That way, you can tell them: “if the login form looks different, don’t type your credentials there”, which is the way to minimize phishing.

[Steve Briggs]

Hi Jaime - 

Thanks once again - that is a very good question, and I agree using SAML for a single application is overkill. However, here is why we are doing this:

Our client's application has been running fine for years with its own internal authentication. Now the client wants the application to hook into an external provider's service using SSO, so that the user can log in to our application, use the application, and at any time while logged in click on a link to the new external SP, without having to login again, and passing their attributes in the process. They will not (or at least should not) be starting the process from the new external SP - they will (or should) always initiate the flow from our application. They cannot log in directly to the new external SP. This, in answer to your question, is the only reason we are implementing SAML.

Now that I have set up the IdP for this purpose using SSP (same server as the application but different virtual host), you and Peter both highly suggested using the new IdP for logging in to our application instead of the hack I wrote using a PHP session ID stored in the database and retrieved by the IdP. I agree with you that that would be the best way to go, but I want to maintain the same UI for logging in that we have always had for years, even if the URL is now different (the IdP domain, though different, is still that of the parent organization and therefore can be trusted by the user). If someone tries to access a protected area of our application OR the new external SP, they will be directed to the same login page on the IdP, that would ideally look like our application that they are familiar with. If the login page were to look like the default SSP login page, they would be totally confused.

So, to return to my original question, what is the best way to integrate our application login with the IdP as seamlessly as possible in terms of UI/UX?

Thanks!

[Peter Schober]

* Steve Briggs <st...@wowpages.com> [2016-09-05 17:16]:

> Thanks once again - that is a very good question, and I agree using SAML
> for a single application is overkill. However, here is why we are doing
> this:
>
> Our client's application has been running fine for years with its own
> internal authentication. Now the client wants the application to hook into
> an external provider's service using SSO

You've explained and we've discussed all this before in the thead
"How to bind user variables to attributes?". So everything I said
there still applies.
-peter

[Steve Briggs]

Yes - thanks Peter, I understand, and I appreciate your earlier comments, which have convinced me to follow your advice about moving the application sign on to the IdP. I'm just looking for guidance on maintaining a consistent UX across the application and the login page.

[Peter Schober]

* Steve Briggs <st...@wowpages.com> [2016-09-05 18:38]:

> Yes - thanks Peter, I understand, and I appreciate your earlier comments,
> which have convinced me to follow your advice about moving the application
> sign on to the IdP.

While that's recommended (and what Jaime has been saying all along)
that's not what I said when trying to answer your literal question:
That was about how to properly bootstrap an SSP session (as SAML IDP)
transparently from an existing application session, without credential
replay or other ugliness.
The provided example
./modules/exampleauth/lib/Auth/Source/External.php should be usable
for you with only minor modifications (grab the data from /somewhere/
-- maybe another session or data source -- and put it into an SSP
session and return), at least if you're certain no direct
(SP-initated) access to the "external" application happens or needs to
be supported.

If OTOH you intend to move the login UI (and password processing) from
the application to SSP then you'll can create your own theme (within
your own module) and implement whatever UI you want there, but using
SSP's built-in "themeing" API.
https://simplesamlphp.org/docs/stable/simplesamlphp-theming
First you'd succeed in turning your application into a SAML SP,
externalize authentication and implement attribute-based authorization
in the application. (Possibly everyone authenticating to the app so
far is also considered authorized. Going forward that may not be the
case when authentication is externalized.)

Cheers,
-peter

[Steve Briggs]

Thank you Peter - your response is very helpful. That's exactly what I was looking for. I will weigh my options as far as how to proceed.

[Hakim Hari Kishan]

In an attempt to deal with the anxiety and stress of people in the big cities, there are lots of options available to do away with this feeling. Sexology is one of the most popular things which helps overcome the issues related to this. It helps you get your desires in control, and also helps in realizing your desires. There are different kinds of sexologists in the delhi which you can choose from depending on your need.
https://bit.ly/3CcCK9o https://bit.ly/3CeWvNl https://bit.ly/3E3ReIc