<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 22, 2013 at 2:33 PM, Kevin P. Foote <span dir="ltr"><<a href="mailto:kpfoote@iup.edu" target="_blank">kpfoote@iup.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On Thu, 22 Aug 2013, Christopher Bongaarts wrote:<br>
<br>
> On 8/22/2013 3:17 PM, Brewer, Edward L wrote:<br>
>><br>
>> I am currently running a 2.3.6 IdP Instance on JBOSS 5 (RHEL 5) that is<br>
>> configured for UserPassword and PreviousSession for the login handlers. I<br>
>> have JAAS configured correctly to use one of our LDAP sources (it is in<br>
>> production and working correctly). I was just handed a requirement to<br>
>> integrate with an application that wants to authenticate against a<br>
>> differing version of LDAP. I read through the section on JAAS<br>
>> configuration and felt confident I could stack the LDAP servers in the<br>
>> configuration to allow for auth to either service. However, this new LDAP<br>
>> that I am adding is a superset of the current system. More precisely, when<br>
>> we add a new user to our system we add that user in LDAP1(currently<br>
>> configured) and LDAP2(want to add). We keep these systems in sync for the<br>
>> user while they are here. When they leave, we disable the user in LDAP1<br>
>> (but leave their entry) and stop updating LDAP2. So the user is in both<br>
>> but is only able to login to LDAP2. Now, the concern is that if a user<br>
>> leaves and now is able to login to LDAP2, they will be able to get access<br>
>> to an application that assumes they are enabled in LDAP1. I have been<br>
>> given till tomorrow to dream up a way to ensure that if a user is auth'ed<br>
>> in LDAP2 that they will not be allowed in any of the current applications<br>
>> that are configured now.<br>
>><br>
><br>
> One possibility would be to use two login handlers, one configured for LDAP1<br>
> (default) and one for LDAP2 (selectable with a particular authentication<br>
> method you dream up). Then ask the new app to request that authentication<br>
> method (or define a separate RelyingParty for them with that as their default<br>
> auth method).<br>
><br>
> Disclaimer: I don't use the UserPassword/JAAS so I apologize if there are<br>
> limitations that prevent this from working...<br>
<br>
</div></div>I think Chris is right on the front side.. your LDAP2 specific app could<br>
request a special handler. But, the PreviousSession<br>
handler is where things run into issues and your LDAP2 group will have<br>
access to stuff they should not.<br></blockquote><div><br></div><div>Yes, but you could still solve that by making disabled users in LDAP1 invisible to the Attribute Resolver. They'd then be able to authN, but no attributes for them would be returned. Hopefully your downstream apps are not performing AuthN == AuthZ. </div>
<div><br>Dave</div><div><br></div></div>-- <br>David Langenberg<div>Identity & Access Management</div><div>The University of Chicago</div>
</div></div>