Quantcast

Delegating Shib IDP authentication to an external CGI

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Delegating Shib IDP authentication to an external CGI

Losen, Stephen C. (scl)-2
Hi folks,

We are currently using RemoteUser for IDP authentication.  Unfortunately, the underlying SSO is Pubcookie, which has not been supported for years.  We want to eliminate our IDP's dependence on Pubcookie, but we have a rather elaborate Pubcookie login CGI.  Rather than completely re-implement this CGI in the IDP itself using Spring and Web Flows, it may be easier (for me) to rip out the Pubcookie bits in the CGI and pass the principal name to the IDP some other way.  The IDP would redirect the browser to the CGI, which would interact with the user and redirect the browser back to the IDP with the principal name and proof such as a digital signature.

It looks like I should use "authn/External", so I need to write a servlet that redirects the browser to the CGI and later receives the principal name from the browser when the CGI redirects it back to the IDP. I have programming experience (C, ruby, perl) but don't know much java.
I've never used Spring or written a servlet, but I'm willing to learn enough to accomplish this.  Example code would help a lot.

Is this a reasonable approach?  Or is there something much better or easier that I have overlooked?

Thanks for any advice or suggestions you may have.

Stephen C. Losen
ITS - Systems and Storage
University of Virginia
[hidden email]    434-924-0640


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Delegating Shib IDP authentication to an external CGI

Cantor, Scott E.
On 5/19/17, 7:54 AM, "users on behalf of Losen, Stephen C. (scl)" <[hidden email] on behalf of [hidden email]> wrote:

> The IDP would redirect the browser to the CGI, which would interact with the user and redirect the browser back to the IDP with
> the principal name and proof such as a digital signature.

I don't think that would be "easier", it's a good recipe for a security hole if you don't know enough about what you're doing. But it is the only way to implement it without Java alone because there's no inherently secure way to communicate the identity back into the code.

> It looks like I should use "authn/External", so I need to write a servlet that redirects the browser to the CGI and later receives the
> principal name from the browser when the CGI redirects it back to the IDP.

That step is a SSO protocol, one you would have to invent if you don't deploy something. You'd be better off staying on pubcookie I suspect. Even if it is fully left to your own devices to support, at least it's a known-secure approach at present.

> I have programming experience (C, ruby, perl) but don't know much java.
> I've never used Spring or written a servlet, but I'm willing to learn enough to accomplish this.  Example code would help a lot.

Some Java servlets that implement the external login interface are included in the IdP, see [1][2].

> Is this a reasonable approach?  Or is there something much better or easier that I have overlooked?

I think if I were you I would dump the CGI personally, but not knowing what it does that's difficult to assess.

-- Scott

[1] net.shibboleth.idp.authn.impl.RemoteUserAuthServlet
[2]  net.shibboleth.idp.authn.impl.X509AuthServlet


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Delegating Shib IDP authentication to an external CGI

Jim Fox
In reply to this post by Losen, Stephen C. (scl)-2

> 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 [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Delegating Shib IDP authentication to an external CGI

Losen, Stephen C. (scl)-2
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
[hidden email]    434-924-0640


-----Original Message-----
From: users [mailto:[hidden email]] On Behalf Of Jim Fox
Sent: Friday, May 19, 2017 11:53 AM
To: Shib Users <[hidden email]>
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 [hidden email]
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Delegating Shib IDP authentication to an external CGI

Cantor, Scott E.
> 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.

You certainly have a perfect storm there to work with. All of it is doable but you would have to develop the right scripting rules in the MFA method to orchestrate all of it, and you'll have to learn a lot to get to that point.

As for the "task enforcement" part, that's an interceptor in the IdP, it doesn't belong in the login flow.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Delegating Shib IDP authentication to an external CGI

Jim Fox

>> 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.
>
> You certainly have a perfect storm there to work with. All of it is doable but you would have to develop the right scripting rules in the MFA method to orchestrate all of it, and you'll have to learn a lot to get to that point.
>
> As for the "task enforcement" part, that's an interceptor in the IdP, it doesn't belong in the login flow.

Adding to that:

1) It is quite easy to write a REST capable authentication verifier bean and incorporate it into the MFA flow.
2) It is a whole lot more enjoyable to code MFA flows than it is to work on pubcookie.
3) We had some web clients, iSomethings, that could not negotiate the external flow.  They work fine with a native MFA flow.
4) For your pubcookie clients: while it is trivially easy to clusterize mod_pubcookie, far as I know mod_shib still requires a short bit of session host affinity.

Jim
--
To unsubscribe from this list send an email to [hidden email]
Loading...