custom authentication

[Roman CHRENKO]

Hi.
You wrote that "I have also configured IDP that can provide SSO functionality".
So how do you deliver SSO cookie from IDP to a client's browser?
You must from you application:

-        login to IDP by REMOTE_USER mechanizm (I recommend to use other header name),

-        secure IDP (it can be accessible only from your application),

-        but mainly - send SSO cookies to the client. If your application stays between the client and the IDP, you have to resend IDP's SSO cookies to a client or issue your own SSO cookie and keep a map of "your cookie <=> IDP cookie" inside your application.
As I wrote in my previous post, it works for me well without the exception you described (I resend IDP's cookies, I don't use inner map.).

Roman


From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Virajitha Sarma
Sent: Monday, October 31, 2016 11:03 AM
To: users at shibboleth.net
Cc: Nitesh Singh <nitesh.singh at globallogic.com>
Subject: Re: custom authentication

Hi,

I have a web application(SAML enabled serviceprovider) with its own login page. I have also configured IDP that can provide SSO functionality. Instead of using the IDP login page, I want to use my web applications login page for taking in user credentials and authentication.
I came across this resource which talks about the same requirement. But the solution provided is not very clear.
https://lists.internet2.edu/sympa/arc/shibboleth-users/2008-07/msg00704.html

solution copied from the URL:
I have done similar implementation here and you might find it useful.
I modified Remote authentication by using the concept of UserPassword
authentication.

1. Implement a servlet (or similar) on legacy web application and have
it protected by legacy authentication mechanism.

2. On shibboleth IDP, Redirect user to legacy web application's
protected servlet. Protected servlet will insure that the login happens
first.
>>> In IDP, where does this configuration go.

3. After successful authentication, protected servlet opens back channel
HTTPS connection to pass user profile to IDP and then redirects user
back to IDP's RemoteUser endpoint.
>>>there are 2 points here: 1. send user profile to IDP
and 2. redirects user back to IDP's RemoteUser endpoint
Are these actions carries out so that IDP can maintain a user
session?
When I try to access Remoteuser end point I am getting "No
conversation key found". I am not able to find any documentation
on what is the conversation key?
Could you please provide some inputs on this?

In the whole conversation between legacy web and IDP, a unique one time
session key and return URL were the key factors to relate all the
communication.

-Anurag Sharma
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20161031/b68fb2ac/attachment-0001.html>