Custom authentication and extending the login.jsp element.

Fri Aug 31 11:59:14 EDT 2012

Ah,yes.  Forgot about that call o the auth engine. To my mind that came in at a different point.

It looked to me that I had control flow like this:

1) Shib intercepts attempt to reach resource via apache plugin,
2) Control passed to my Custom Auth Servlet,
3) Servlet redirects to login.jsp,
4) Login.jsp has FORMACTION that goes to j_security_check (which disappears inside the container),
5) Control passed back to my Custom Auth Handler,
6) I take uid/password and do my custom thing,
7) Based on results, I set a flag and return to AuthnEngine (via the call you mention).

So,  If I change step (3) and redirect to a JSP of my own making, that jsp has to take an action that will get me back to the same point that the login.jsp's FORMACTION did. But I don't know what login.jsp does there since it "disappears" inside the container. 

Am I overcomplicating this,  missing something basic that everyone else in the world understands,  or just plain dumb?

Martin

-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Paul Hethmon
Sent: Friday, August 31, 2012 11:46 AM
To: Shib Users
Subject: Re: Custom authentication and extending the login.jsp element.

Martin,

Did you fully implement a login handler and servlet? If so, in your servlet, you have a call to:

	AuthenticationEngine.returnToAuthenticationEngine(request, response);

That's where you are sending control back to Shib.

I understand wanting to keep components separate, but you're pretty much going to have to push your jars and resources into the war file at some point, web applications just require that. I maintain all of my code in independent projects. Then I package up a Shib distribution that includes my jars in it. That's my base distribution that I use. It's pretty much the standard Shib distribution with the addition of those files I created.
In my case, I actually do a bit more to modify the base Shib, but the idea is the same.

Paul

On 8/31/12 11:35 AM, "PARDEE, MARTIN  (MARTIN)" <mlp at research.att.com>
wrote:

>Paul, thanks.
>
>That seems consistent with what I see, I just didn't want to have to 
>package my entire authentication app into idp.war.  I am sure you'll 
>understand the desire to keep things separated into components.
>
>
>Can you tell me how one should "send control back to Shibboleth"?
>
>I am uncertain of how login.jsp does this.  The j_security_check FROM 
>action in login.jsp seems to disappear into the container and I have 
>NOI idea what connects things back to Shibboleth.  I only know that 
>after redirecting to login.jsp and collecting a UID, I am magically 
>returned to my CustomAuthHandler servlet in a second call to the service method.
>
>
>Martin
>
>
>-----Original Message-----
>From: users-bounces at shibboleth.net 
>[mailto:users-bounces at shibboleth.net]
>On Behalf Of Paul Hethmon
>Sent: Friday, August 31, 2012 11:08 AM
>To: Shib Users
>Subject: Re: Custom authentication and extending the login.jsp element.
>
>Just replace login.jsp with one of your own. Once you are in the login 
>handler, you own the user experience and interface until you send 
>control back to Shibboleth. But it is a web application, so your 
>resources (pages,
>etc) must be available in the context of the web application. The 
>easiest is to include them in the war file.
>
>Paul
>
>On 8/31/12 11:02 AM, "PARDEE, MARTIN  (MARTIN)" <mlp at research.att.com>
>wrote:
>
>>Folks:
>>
>>Back in June I started integrating a custom login handler for 
>>Shibboleth, which I have done.
>>
>>The custom handler uses a web service to launch a phone call to do 
>>biometric authentication on a smart phone.
>>
>>In case I forgot to,  thanks to everyone who took the time to answer 
>>my (sometimes naive) questions in the past.
>>
>>In order to extend this prototype to include multiple devices per user 
>>(an iPhone, iPad, Android whatever) I need to ask the user for more 
>>than just A user ID prior to proceeding with custom authentication.
>>
>>This has led me to the following dilemma:
>>
>>Once I enter my shibboleth Custom Auth Handler (a servlet in idp.war) 
>>I carry on my conversation through login.jsp.
>>
>>Once inside login.jsp,  it appears that I have only one opportunity to 
>>obtain user data:  j_username and j_password are all that this jsp 
>>allows.
>>
>>
>>What I would really like to do is redirect to a JSP (other than
>>login.jsp) in a different Webapp, which would allow me to develop a 
>>user interface that I can extend in any way I need to.
>>
>>If I attempt to use request.getRequestDispatcher().include or 
>>.forward, I get server side errors (presumably because I'm trying to 
>>invoke things outside of the idp.war webapp.
>>
>>So my conclusion here is that the only way that I can make my user 
>>interface any richer than login.jsp is to bring ALL of the resources 
>>that I need for authentication support inside of idp.war. Somehow this 
>>just seems wrong.
>>
>>It seems obvious that shibboleth was designed to "bridge" to external 
>>authenticators. This being the case, there must be a mechanism in here 
>>somewhere that will permit me to interact with the user in a richer 
>>way than what is available in login.jsp.
>>
>>Would someone please help me understand what my options are here?
>>
>>
>>Thanks
>>
>>
>>Martin Pardee
>>
>>
>>
>>
>>
>>
>>
>>--
>>To unsubscribe from this list send an email to 
>>users-unsubscribe at shibboleth.net
>
>--
>To unsubscribe from this list send an email to 
>users-unsubscribe at shibboleth.net
>--
>To unsubscribe from this list send an email to 
>users-unsubscribe at shibboleth.net

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net