[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] Thanks - STS up and running

No, that falls under #4, "Document the LDAP CP".  I was referring to what I thought was the cause of the unknown identity object being passed to the LDAP CP.  That is, the issue that was causing the: "Unsupported AuthN materials" exception.  Maybe that was cause by #1?  Regardless, what was the solution to the "Unsupported AuthN materials" issue?  Or is that what happens with your directory server and not on WAG?

Anyway, we'll work with you to look into the cause of your directory's inability to "authenticate" today.

Tom

>>> Michael McIntosh <mikemci@xxxxxxxxxx> 02/05/07 5:36 AM >>>
I think what Tom is asking about is previously undocumented requirement to 
make changes to the LDAP CP Configuration file:
        <bci:env prop="java.naming.security.principal" value="cn=user" /> 
        <bci:env prop="java.naming.security.credentials" value="password" 
/> 

I am still not able to use the cardKey attribute to "authenticate" to the 
LDAP server (this is a search string actually, as the authentication is 
based on a user with access to all of the entries) when using self signed 
credentials. As Jim pointed out, this code works when running on WAG but I 
there must be additional undocumented configuration requirements needed to 
get it running with my directory.

Additional comments interspersed with Jim's original text below:

higgins-dev-bounces@xxxxxxxxxxx wrote on 02/04/2007 11:28:58 PM:

> I wasn't part of that specific conversation either, so I'm not sure.
> I saw the issue where you and Mike were talking about the registry 
> changes -- was there also a change to what goes in java.security? 
> Or maybe the issue is that the STS wasn't using the java.security 
> registry mechanism previously, and is now (in which case, the first 
> part of #4 below would be part of the same issue).
> 
> Jim
> 
> >>> "Tom Doman" <TDoman@xxxxxxxxxx> 2/4/07 8:48 PM >>>
> Don't we also need to document a java.security configuration 
> requirement?  I didn't catch the details but I know this caused a 
> lot of head scratching this weekend.
> 
> Tom
> 
> >>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 02/04/07 6:34 PM >>>
> As of 20070204244515Z, the Higgins STS on wag started returning 
> valid RSTRs for self issued user authn types. (single-signon thingy)

As I pointed out - this took longer than I'd have liked due to 
inconsistent behavior between the Wag LDAP Server and my own.

> Before the celebratory beer deletes too many relevant brain cells, I
> just wanted to note some of the integration items we haven't yet written 
down:
> 
> 1) STS server needs  Java Cryptography Extension (JCE) Unlimited 
> Strength Jurisdiction Policy Files 5.0 (link).  The zip file 
> contains two jars that must be copied to 
> <JAVA_HOME>/jre/lib/security.  The STS should probably log some very
> specific error message if it senses this problem.

I agree - right now there is an exception related to invalid key size, 
I'll try to handle this an put out a "useful" message.

This is because Java is distributed with crypto libs limited to 128 bit 
encryption and CardSpace encrypts tokens with 256 bit encryption. People 
in certain countries can download license jar files that remove the key 
size restriction.

> 2) xalan.jar is an additional dependency not noted earlier (dl from 
here)

Again, this is another case of classes included with IBM JRE not being 
included Sun JRE.

> 3) build.xml files must be re-generated before building -- to get 
> around this, we need to move on the plan to use ./lib directories 
> for dependencies.

I've made and checked this change in.

> 4) Existing deployments need to update their Configuration.xml. 
> What goes in Configuration.xml should probably be documented on the 
> deployments pages.  Same can be said about the CP config.

Hopefully this week.

> 5) Life would be much easier if we checked in the LDAP CP to 
> Eclipse.  Can we go ahead and do this (even though the dependency .
> jars are still in a holding pattern)?

This would help prevent a lot of problems. This would have identified 
issue with IdAS interface changes breaking the CP and would make it easier 
to ensure that IdAS and CP jars were consistent with each other and would 
allow source lines to be provided for exception logs.

> 6) For public deployments, we need staging servers.  Someone (looked
> like Dale) was running tests at the same time as us.  This not only 
> made log file parsing hard, but may have made Dale scratch his head 
> a few times as we were bouncing tomcat over and over.
> 
> 7) log file is getting way too much debug info now, we need to figure 
out why.
> 
> 8) We need to implement the update methods for the LDAP CP.  Now 
> Mike has jndi code and Daniel has php code to do this.  We should be
> able to share code once we have it working in the CP.
> 
> 8.1) Also need to document the need for / use of java.naming.ldap.
> attributes.binary when updating binary attributes like cardKey
> 
> 
> Jim
> 
> 
> 
> >>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 2/2/07 6:15 PM >>>
> Maybe Pat meant to put a delayed delivery on that message :)
> 
> >>> Anthony Nadalin <drsecure@xxxxxxxxxx> 2/2/07 7:18 AM >>>
> 
> Will this be the Bandit STS ?
> 
> Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
> "Pat Felsted" <PFELSTED@xxxxxxxxxx>
> 
> 
> "Pat Felsted" <PFELSTED@xxxxxxxxxx> 
> Sent by: higgins-dev-bounces@xxxxxxxxxxx 
> 02/01/2007 08:11 PM Please respond to
> "Higgins \(Trust Framework\) Project developer discussions" 
> <higgins-dev@xxxxxxxxxxx>
> 
> 
> To
> <higgins-dev@xxxxxxxxxxx>
> 
> 
> cc
> 
> 
> 
> Subject
> [higgins-dev] Thanks - STS up and running
> 
> 
> 
> Thanks to everyone who has worked so hard to get the STS in working 
> order again. We will be showing this at RSA next week so it is much 
> appreciated. BTW, I have tested it against Kim Cameron's blog and 
> Pamela Dingle's Wordpress plugin and it is working great. The single
> sign for I-Cards is especially impressive.
> 
> Thanks!
> Pat_______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx 
> https://dev.eclipse.org/mailman/listinfo/higgins-dev 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx 
> https://dev.eclipse.org/mailman/listinfo/higgins-dev 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx 
> https://dev.eclipse.org/mailman/listinfo/higgins-dev 

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/higgins-dev