<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Hi Scott,</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">All the applications (not shibboleth SP's but support SAML) trying to achieve SSO using Shibboleth IDP( based on SAML) should have only common login parameters like username and password for authentication? The reason I am asking this is, my web application requires additional parameter say a "location" for login. In such a scenario, will I not be able to achieve SSO login. I would not use federated word in my case as all the web applications that participate in SSO are on the same domain. Say a facebook, twitter, instagram are trying to achieve SSO, it might be possible that any of these applications might be having additional login parameters, then how can they achieve federated login(using federated here as these application reside in different domains)?</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Thanks</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Virajitha</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 1, 2016 at 6:31 AM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> This discussion is really very helpful. I was thinking that this remote_user is an<br>
> endpoint which users can use in case of any custom authentications. My<br>
> main requirement being using my applications login page instead of IDP's.<br>
<br>
That is not a requirement that makes any sense. That is not how federated login works. Your application doesn't have a login page, it issues SAML requests and leaves it to the IdP. If that's not what you want, you don't want SAML or this software.<br>
<br>
> 2. The remoteuser should be configured/protected with a container<br>
> authentication. This is done by changing the edit-webapp/../web.xml.<br>
> Please let me know if this is not required.<br>
<br>
That depends on the container and your architecture. Put Apache in front and you don't have to touch anything in the container.<br>
<br>
> 4. IDP would use "remoteuser" authentication mechanism and display UI<br>
> corresponding to the container authentication configured for this login flow.<br>
> That is basic auth or form authentication.<br>
<br>
There's no reason to be using container authentication like that. You use the RemoteUser flow to integrate with other SSO systems that deploy themselves inside Java or Apache, such as a stand-alone CAS server or an Apache module like pubcookie or cosign. If you're just doing forms or basic-auth, you can just use the IdP alone and use the Password login flow.<br>
<br>
> So, any of the remoteuser, remoteuserinternal and external authentications<br>
> would show the login page of the authentication mechanism(basic auth,<br>
> form login) configured in the container?<br>
<br>
Yes, if you chose to, but that's a poor choice in most cases.<br>
<br>
> And if i want to use my application's login page and send username and<br>
> password from my web application itself, probably set in the request, then<br>
> would I be using CAS-Shibboleth plugin to achieve this?<br>
<br>
No. You cannot do that. It is absolutely wrong.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><br></div><div>Regards,</div><div>Virajitha</div></div></div>
</div></div>