[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [higgins-dev] Demo post-mortem
|
Jim,
I am a little worried about this. I don't think I can use the Tokens
provided by CardSpace to authenticate to the STS to authenticate the STS
to LDAP CP.
For instance, X.509 Authentication involves signing the message from
CardSpace to the STS with a private key and providing the STS with the
associated X.509 Certificate (public key) in order to verify the
signature. The STS does not have access to the private key and cannot
authenticate on behalf of the CardSpace user.
Thanks,
Mike
higgins-dev-bounces@xxxxxxxxxxx wrote on 12/14/2006 12:36:44 PM:
> LDAP does support SASL and it's various mechanisms (including
> Kerberos, GSSAPI, etc). Last I checked, there was interest in, but
> little work done on defining a SAML mechanism for SASL.
>
> Daniel has done more research on this, but the thought may be to
> encapsulate the authN materials needed to open the IdAS context
> inside the self-issued token.
>
> Jim
>
> >>> Michael McIntosh <mikemci@xxxxxxxxxx> 12/14/06 9:39 AM >>>
> Daniel,
>
> I can't make the call but have some ideas on this.
> Currently I use the Username/Password to open the context to access the
> subject's attribute values.
> How could I accomplish that same objective using other token types?
> Can the LDAP CP support any authentication methods other than
> AuthNNamePasswordMaterials?
> Specifically, I'd like it to support SAML, Kerberos, and X.509 in
addition
> to Username/Password of course.
>
> Thanks,
> Mike
>
> higgins-dev-bounces@xxxxxxxxxxx wrote on 12/14/2006 10:59:13 AM:
>
> > I wonder if during the call there would be time to discuss a next
> > potential step for the STS - supporting the other authentication
> > methods of CardSpace? I am specifically interested in being able to
> > experiment with authentication using a Self-issued token. I see
> > this as possibly being a very useful way to achieve single sign-on
> > functionality.
> >
> > Daniel Sanders
> >
> > >>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 12/13/2006 7:07 PM >>>
> > Thanks for doing this Jim. Let me know if you'd like to go over some
> > of this on the call tomorrow. -Paul
> >
> > From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-
> > bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
> > Sent: Wednesday, December 13, 2006 7:44 PM
> > To: higgins-dev@xxxxxxxxxxx
> > Subject: Re: [higgins-dev] Demo post-mortem
> >
> > FWIW, I put these here and took the liberty of assigning some names
> > to tasks (still need owners for a few)
> >
> > >>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 12/8/06 3:57 PM >>>
> > Add to the list:
> >
> > - STS Configuration
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=163618
> > ). The bug doesn't say anything else, but I think it has to do with
> > how the STS is configured to do things like: - insert a claim mapper
> > between itself and the IdAS CP (dependency on claim mapping task
> > below), possibly include a list of allowed CP's, etc.
> >
> > - Name mappings. We used full DN values from the groupMembership.
> > Should have been simple (mapped) names.
> >
> > - Update operations in IdAS instead of PHP LDAP. All the update
> > operations on the RP use PHP LDAP instead of IdAS.
> >
> > - Location of dependency libraries. We had some in the STS
> > deployment lib directory, and others in the Tomcat shared lib. We
> > need a methodology for deciding where to locate these.
> >
> > - BasicDateTimeValue couldn't be used because of some fishiness with
> > the time zones. Duane has the details.
> >
> > - Verify that Mike's latest STS code is in, and we can build and
> > deploy ourselves.
> >
> > - Check in fixes to card generator to Higgins. Separate from form ui
> >
> > - Empty/missing claim (on forum)
> >
> > - LDAP CP should support any URI as the context ref (i.e. http)
> >
> > Jim
> >
> >
> > >>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 12/7/06 5:47 PM >>>
> > I suggested that we do some kind of post-mortem evaluation of the
> > work done to get the demo working so we avoid letting things fall
> > through the cracks.
> >
> > Probably the best thing to do is get everyone's feedback and then
> > create a task list or create bugzilla items for each.
> >
> > The Novell team will meet tomorrow afternoon to come up with a list
> > from our experience, so look for the results of that later. Until
> > then, a few I can think of off the top of my head include:
> >
> > - CardID to context mapping. We ended up making the CardID equal
> > the contextRef. It looked like this: file:///<some path on the IdAS
> > machine to a config file>?<some identifier inside the config file
> > representing a context>. There's already a bug for this (https:
> > //bugs.eclipse.org/bugs/show_bug.cgi?id=163366). It would be nice
> > if we could come up with something a little more abstract so we're
> > not putting something as brittle and revealing as a local filename
> >
> > - Claim/Attribute mapping. We ended up making the LDAP CP emit
> > attributes which are named just like cardspace claims... We'd like
> > to do this via configuration, or possibly a mapping CP, or
somethinglike
> that.
> >
> > - STS builds are still not quite up to snuff -- see recent list
traffic.
> >
> > I can see there are a lot of others now that I look around, I have
> > to run for the evening so I'll pick back up in the AM.
> >
> > Jim
> > _______________________________________________
> > 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
