Delegating Shib IDP authentication to an external CGI

[Losen, Stephen C. (scl)]

Hi Jim,

Thanks for the suggestion.

Yes I completely rewrote the Pubcookie login CGI, but not the Apache module mod_pubcookie.  I think I can port most of the CGI functionality into the IDP itself.

Our login CGI checks three password stores.  We check two completely independent Windows DCs (Academic and Health System).  And we check an internally developed web application, which is pretty basic. The CGI HTTP POSTs the username/password (and other stuff) to the web app which returns success or failure.  This third password store is for applicants for admission, alumni, etc., for whom we do not have Windows AD identities.

The CGI also has a button to login with your personal client cert.  The button links to a different URL for the login CGI that is configured to require a client cert.  Apache httpd renegotiates the SSL connection and passes the client cert information to the CGI via environment variables.  I see that the IDP has X509 support.

I recently added Duo second factor to the CGI.  We are in transition so we have a LDAP attribute that indicates if the user is registered with Duo.  If not, the CGI skips the Duo step (since it cannot succeed).  Eventually Duo will be required for everyone, so the IDP may not need to check LDAP.  But I think I can set up an activation condition based on the attribute if necessary.

We also have an "enhanced" login that Duo will replace, since Duo has better assurance.  Our enhanced login is a second factor where you need to enter your University ID card number and answer a personal security question.  This is not used much.

And years ago some genius decided that we should use our login CGI to nag people when they have unfinished tasks to complete.  For example, Virginia state law requires all students to fill out a form where they indicate any felony convictions (response to Va. Tech massacre?)  We also require students to take training for alcohol abuse, sexual/racial discrimination, etc.  I think these are Federal requirements. So we have an LDAP attribute that lists unfinished tasks with deadlines.  If you have any, the CGI puts up an extra page listing the tasks, web links to them, and deadlines.  If any are past the deadline, then the CGI will not give you credentials (the granting cookie) unless you are trying to access an unfinished task.  I may be able to get my management to abandon this feature since it could seriously slow down migrating off our pubcookie login CGI.  Maybe we could enforce this stuff elsewhere.

>From what I can tell, checking two Windows DCs for passwords should not be a problem, nor the X509 cert, nor Duo.  I may need to write a flow to talk to our password verifying web app.  If something already exists, then maybe I could get the app modified to work with an existing module.  The CGI connects directly to the web app, this is not a browser redirect.

Perhaps I also need to explore JAAS.

If my management insists that the IDP support all the features of the existing CGI, then I may need to remove the pubcookie code from the CGI and hook it up to the IDP authn/External somehow.

As you know, the mod_pubcookie module only runs on Apache httpd 2.2 and will never be ported to 2.4 or beyond.  Currently our IDP sits behind an Apache httpd 2.2 reverse proxy running mod_pubcookie and uses RemoteUser.

Stephen C. Losen
ITS - Systems and Storage
University of Virginia
scl at virginia.edu    434-924-0640


-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Jim Fox
Sent: Friday, May 19, 2017 11:53 AM
To: Shib Users <users at shibboleth.net>
Subject: Re: Delegating Shib IDP authentication to an external CGI


> We are currently using RemoteUser for IDP authentication.  Unfortunately, the underlying SSO is Pubcookie, which has not been supported for years.

We are near the end of a transition from Pubcookie and remoteuser authentication to the native Password flow.
It has been remarkably easy.  And that includes porting our support of multiple 2nd factors (Entrust and Duo) 
and the stripping of all those '@whatevers' that people add to their ids.  We ask for netid and they enter their email. 
Thank you Scott for that Password.Transforms bean.

Unless you've done some complete rewrite of pubcookie I think transitioning to native Password flow is the easiest and best way to go.

Jim

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