<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Dec 16, 2016 at 3:18 PM Peter Schober <<a href="mailto:peter.schober@univie.ac.at">peter.schober@univie.ac.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* C G <<a href="mailto:ci_98yr@yahoo.com" class="gmail_msg" target="_blank">ci_98yr@yahoo.com</a>> [2016-12-16 16:09]:<br class="gmail_msg">
> We have a self sustained web app on iis with its own login and password store.<br class="gmail_msg">
><br class="gmail_msg">
> We want to add a layer to that local authentication. As such we are<br class="gmail_msg">
> looking at a two step process a) first auth happening on Idp with<br class="gmail_msg">
> shib sp intercepting and creating a valid session for the app we are<br class="gmail_msg">
> looking at and b) the next step of local authentication as regularly<br class="gmail_msg">
<br class="gmail_msg">
Add a Shib SP to the web server then and enforce Shib sessions.<br class="gmail_msg">
<br class="gmail_msg">
Since you don't want to do something about the (then redundant) local<br class="gmail_msg">
authentification in the application you're done.<br class="gmail_msg">
<br class="gmail_msg">
> What are the options or how is it done to ensure Userid is<br class="gmail_msg">
> consistent across two steps ?<br class="gmail_msg">
<br class="gmail_msg">
If someone can auccessfully authenticate at your IDP (and fulfill<br class="gmail_msg">
whatever authorization rules you add to your SP) *and* that someone<br class="gmail_msg">
can also authenticate to your local application successfully, why<br class="gmail_msg">
bother?<br class="gmail_msg">
<br class="gmail_msg">
While you could pull out an identifier from the SP's session and<br class="gmail_msg">
enforce that as username in the local application username form filed,<br class="gmail_msg">
that's only a inconvenience to subjects (who then cannot change the<br class="gmail_msg">
username in the form) but does not prevent a malicious client from<br class="gmail_msg">
submitting that same HTML form with other data.<br class="gmail_msg">
<br class="gmail_msg">
> Use of remote_user session variable, but web app is old and we don't<br class="gmail_msg">
> have access to code to modify<br class="gmail_msg">
<br class="gmail_msg">
I don't understand the first part of the above sentence, and AFAIK<br class="gmail_msg">
MS-IIS does not support REMOTE_USER.<br class="gmail_msg">
<br class="gmail_msg">
> I am sure this is a well understood problem :) and solved?<br class="gmail_msg">
<br class="gmail_msg">
Not quite. The common (and sensible) goal is to get rid of the local<br class="gmail_msg">
authentication and *replace* it with federated/externalized<br class="gmail_msg">
authentication, plus add local authorization rules as needed to the<br class="gmail_msg">
Shib SP.<br class="gmail_msg">
If that is not deemed sufficiently secure you'd add more factors into<br class="gmail_msg">
the externalized authentication prozess at the IDP, when accessing<br class="gmail_msg">
this application.<br class="gmail_msg">
-peter<br class="gmail_msg"></blockquote><div><br></div><div>I'm really late to the game here as Google Inbox dumped this into spam annoyingly.</div><div><br></div><div>I've done this with a Java web application following the guidance in Stefan Rasmusson's book "A Guide to OpenSAML." The book isn't super-deep, but it isn't expensive and got me past the hump of bridge OpenSAML's APIs to my existing understanding of SAML so I could write a simple embedded SP implementation for J2EE apps.</div><div><br></div><div>I modified Stefan's approach somewhat to accept HTTP-POST redirect SAML authentication and check correct assertion signing rather than using artifact auth because our customers have IdP's that are not accessible to our servers.</div><div><br></div><div>The SP implementation with OpenSAML isn't too complex. You can write a Servlet filter to check if the session is authenticated. If authenticated, the filter passes onto the application's Servlets. If not, the filter redirects to the IdP and the consumer servlet checks the assertion and redirects back to the originally requested page.</div><div><br></div><div>We have a multi-tenant app with a complex JAAS RBAC system. OpenSAML works very well for us as it gives us a great degree of flexibility.</div><div><br></div><div>Using the SP in Apache will work for most use cases, but we couldn't get it to work for our needs.</div></div></div>