MemCached StoragesService Compatibility

[Douglas E. Engert]

On 1/11/2012 9:06 AM, Esmeralda Câmara wrote:
> Hi Manuel,
>
> Yes, x509 authentication was working ok before the Memcached Storage Service.
>
> The only difference from the instructions on
>
> https://wiki.shibboleth.net/confluence/display/SHIB2/X.509+Login+Handler
>
> Is that I had to change the filter in data connectorbecause I need SERIALNUMBER=BI<VALUE> to match my users on LDAP.
>
> <resolver:Dependency ref="x500Principal" />
>
> <dc:FilterTemplate>
>
> <![CDATA[
>
> #if( !$x500Principal.Empty )
>
> #set( $subject = $requestContext.getUserSession().getSubject())
>
> #set( $sub_str = $subject.toString() )
>
> #set( $dn = $sub_str.split(", ") )
>
> #foreach( $item in $dn )
>
> #if( $item.startsWith("SERIALNUMBER=BI") )
>
> #set( $size = $item.length() )
>
> #set( $last_pos = $size - 1 )
>
> #set( $serial = $item.substring(15,$last_pos) )
>
> #end
>
> #end
>
> (info=$serial)
>
> #else
>
> (sAMAccountName=$requestContext.principalName)
>
> #end
>
> ]]>
>
> </dc:FilterTemplate>
>
>
> But before the Memcached Storage Service it was working fine.
>
> In attached a new file with log lines.
>
> Thanks
> Esmeralda
>
> On 11-01-2012 14:13, Manuel Haim wrote:
>> Hi Esmeralda,
>>
>> thank you for sending your logs. Now, I will see what I can do.
>>
>> Did x509 authentication work for you before, i.e. without the Memcached
>> StorageService?
>>
>> I am still confused there is no error message within your logs, but the
>> log lines seem to tell me the x509 authentication itself is working
>> correctly. The client certificate is read, and its principal is put into
>> the Subject (which will later be read by the attribute resolver).
>>
>> Then I see some output from the Memcached StorageService. The only line
>> which seems to be suspicious to me is
>>
>> 10:39:40.769 - DEBUG
>> [edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter:94] -
>> storageService.contains: session!CN=ESMERALDA ...
>>
>> as it should be followed by a line like "contained global" or "contained
>> nowhere", but it is not.

I don't know if this is the problem, but in the traces without the memcache,
it appears the certificate subject name is converted from ASN.1 to text, and
all the OIDs of the component names are recognized and replaced with short
names: SERIALNUMBER, GIVENNAME, SURNAME. But the memcache has to do:
  Subject subject = ((SessionManagerEntry) value).getSession().getSubject();
It appears some of the OIDs in the subject name are not recognized, so are
replaced with the OID number=value, and string compares in the filer like
#if( $item.startsWith("SERIALNUMBER=BI") )
would most likely fail.

>>
>> Could you send me some more lines, maybe a complete login attempt? I
>> need to see the point where the IdP fails, so I may have a guess where
>> things start to get wrong... it would also be helpful if you enabled
>> TRACE mode in logging.xml, just replace "INFO" with "TRACE" in this line:
>>
>> <logger name="edu.internet2.middleware.shibboleth" level="TRACE" />
>>
>>
>>> Do we have to update or change something on the configuration of x509
>>> login handler similar to what we have done on login.config
>> No. Looking at the X509LoginServlet.java sourcecode and your logs, only
>> a javax.security.auth.x500.X500Principal (which is serializable) is
>> added to the Subject. This should not be a problem.
>>
>>
>>> Another issue  that I notice, when I run tomcat shutdown.sh some java
>>> process ( I think clients of mechached //usr/local/jdk1.6.0_29/bin/java
>>> -Djava.util.logging.config.file=/usr/local/apache-tomcat-6.0.33/conf/logging.properties
>>> -Djava.util.logging.manager=org.apache.juli.ClassLoade ) do not die.
>> That is true, the Memcached connection is not closed automatically.
>> However, when you shutdown tomcat, all ressources are freed, and this
>> one is reported as a "possible memory leak". It would be one, if you
>> only restarted the IdP webapp and not the whole servlet container (i.e.
>> tomcat). According to the Shibboleth team, the IdP is not intended to be
>> restarted itself, but you should always restart the servlet container.
>>
>> In our current development, we added the following code to the
>> UniMrMemcachedStorageService constructor to circumvent this problem (not
>> yet sure if this already works):
>>
>> Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() {
>>    public void run() {
>>      client.shutdown(); // shutdown the memcached client
>>    }
>> }));
>>
>>
>> -Manuel
>>
>> --
>> To unsubscribe from this list send an email tousers-unsubscribe at shibboleth.net
>
>
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444