custom authentication

[Cantor, Scott]

> This discussion is really very helpful. I was thinking that this remote_user is an
> endpoint which users can use in case of any custom authentications. My
> main requirement being using my applications login page instead of IDP's.

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.
 
> 2. The remoteuser should be configured/protected with a container
> authentication. This is done by changing the edit-webapp/../web.xml.
> Please let me know if this is not required.

That depends on the container and your architecture. Put Apache in front and you don't have to touch anything in the container.

> 4. IDP would use "remoteuser" authentication mechanism and display UI
> corresponding to the container authentication configured for this login flow.
> That is basic auth or form authentication.

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.

> So, any of the remoteuser, remoteuserinternal and external authentications
> would show the login page of the authentication mechanism(basic auth,
> form login) configured in the container?

Yes, if you chose to, but that's a poor choice in most cases.

> And if i want to use my application's login page and send username and
> password from my web application itself, probably set in the request, then
> would I be using CAS-Shibboleth plugin to achieve this?

No. You cannot do that. It is absolutely wrong.

-- Scott