[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [higgins-dev] Demo post-mortem
|
A self-issued token, does not have to be based on personal (self issued in
your terms) card.
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Daniel Sanders"
<dsanders@novell.
com> To
Sent by: higgins-dev-bounces@xxxxxxxxxxx
higgins-dev-bounc cc
es@xxxxxxxxxxx "discussions', 'Higgins (Trust
Framework) Project developer"
<higgins-dev@xxxxxxxxxxx>
12/15/2006 12:52 Subject
PM RE: [higgins-dev] Demo post-mortem
Please respond to
"Higgins \(Trust
Framework\)
Project developer
discussions"
<higgins-dev@ecli
pse.org>
Well, to be more precise, a managed card may have, as part of its
definition, a credential type - which specifies what kind of
authentication material needs to be sent to the STS in the RST. There are
four potential credential types supported by CardSpace. One is a
"self-issued credential". A self-issued credential refers to a
self-issued card. When the managed card is selected, the authentication
material that will be sent to its STS is the PPID of the self-issued card.
PPIDs are generated by CardSpace and are RP-specific, so in this
particular context what I mean by "PPID of the self-issued card" is more
precisely stated as follows: "the PPID of the self-issued card where the
relying party is the managed card's STS."
The definition in the managed card looks as follows:
<UserCredential>
<SelfIssuedCredential>
<PrivatePersonalIdentifier>base64 PPID</PrivatePersonalIdentifier>
</SelfIssuedCredential>
</UserCredential>
So, when I said a "managed card whose authentication method is a
self-issued card", what I really meant was all of the above. Implied in
what I said was what you said - ultimately it comes down to the fact that
the authentication method for the STS is a self-issued token, which is
based on a self-issued card.
Daniel Sanders
>>> Anthony Nadalin <drsecure@xxxxxxxxxx> 12/15/2006 10:55 AM >>>
hmmm, you mean "whose authentication method is a self-signed token, as a
self issued card does not make sense
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Inactive hide details for "Daniel Sanders" <dsanders@xxxxxxxxxx>"Daniel
Sanders" <dsanders@xxxxxxxxxx>
"Daniel
Sanders"
<dsanders
@novell.c
om> To
Sent by:
higgins-d higgins-dev-bounces@xxxxxxxxxx
ev-bounce g
s@eclipse
.org cc
"discussions', 'Higgins (Trust
12/14/200 Framework) Project developer"
6 11:04 <higgins-dev@xxxxxxxxxxx>
AM
Subject
Please respond to RE: [higgins-dev] Demo
"Higgins \(Trust Framework\) post-mortem
Project developer discussions"
<higgins-dev@xxxxxxxxxxx>
I'm talking about creating a managed card whose authentication method is a
self-issued card.
>>> Anthony Nadalin <drsecure@xxxxxxxxxx> 12/14/2006 9:34 AM >>>
Please explain, as STS is not an Authentication service, also the STS can
issue self signed tokens today, are you talking about supporting the
concept of "personal cards" ?
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Daniel Sanders" <dsanders@xxxxxxxxxx>
"Daniel Sanders"
<dsanders@xxxxxxxxxx>
Sent by:
higgins-dev-bounces@xxxxxxxxxxx To
"'Higgins (Trust
12/14/2006 09:59 AM Framework) Project
developer discussions'"
<higgins-dev@xxxxxxxxxx
g>
Please respond to
"Higgins \(Trust Framework\) Project cc
developer discussions"
<higgins-dev@xxxxxxxxxxx>
Subject
RE: [higgins-dev] Demo
post-mortem
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 something like 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
