For the sake of simplicity/laziness/time
constraint / etc…, we are currently using an xml file based identity
store. Plan to have ldap integration pretty soon. As well as making the code
open source.
Integration with IdAS is definitely in the
roadmap.
Thks,
- Ashish.
From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Monday, October 30, 2006
8:02 PM
To: Higgins
(Trust Framework) Project developer discussions; bandit-dev@xxxxxxxxxxxxxxxx;
Paul Trevithick; Michael McIntosh
Subject: RE: [higgins-dev] A Higgins integration with cardspace
If we can get
good momentum in integrating the existing Higgins
components, then we hope to keep that going and a cross-platform selector would
be the next logical step.
It looks like
some of what we'll be doing is similar to what you've already done. I
assume you have a specific identity store, have you considered integrating
your STS with the Higgins IdAS?
Jim
>>> "Ashish Jain" <ajain@xxxxxxxxxxxxxxxx> 10/30/06
11:56 AM >>>
FYI.
A crippled yet functional version of our
STS that interoperates with CardSpace (July CTP) is deployed here:
https://infocard.pingidentity.com/idpdemo/account.jsp
https://infocard.pingidentity.com/rpdemo/login.jsp
It lets you get a card from the IdP,
import it to the windows cardspace client and use it to access the RP
application. More details on access here: http://itickr.com/index.php/?p=41.
I'll be interested in testing with the
non-windows identity selector (if one exists).
Thanks,
- Ashish.
From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Friday, October 27, 2006
7:20 PM
To: higgins-dev@xxxxxxxxxxx;
bandit-dev@xxxxxxxxxxxxxxxx; Paul Trevithick; Michael McIntosh
Subject: [higgins-dev] A Higgins integration with cardspace
We're trying to
put together a reference application here that will show some Higgins/cardspace integration.
We hope to
have CardSpace support on a client (in this case IE7 either on Vista, or along with .NET 3) communicating
with a relying party, where the client will use the Higgins
STS and IdAS to answer the RequestSecurityToken sent by CardSpace.
There are a
couple benefits of integrating in this way: 1) The BX, ISS UI, and card manager
components are already there (for information cards). 2) It shows the use
of STS and IdAS as alternate identity providers for managed cards. Once
this is done, we would want to build on it and create an analogous application
which works with firefox on other OS's. These and other forward looking
goals are listed here
and here .
Specifically, we would want to get the HBX / ISS / STS integration up to a
point where similar functionality can be had using all Higgins
components.
Specifically, for
now we think we need:
1) An RP
which is a mediawiki installation. We hope to do AuthN and AuthZ using the
identity obtained.
2) The STS
deployed as a server so it can be pointed at by a managed card which has been
imported into the client's CardSpace registry. My understanding is that
the STS already has this capability. I haven't yet deployed it as a web
service.
3) The
ability to produce a managed card which is signed by and points to the STS (we
hope to start with some code Chuck has for creating this, but it would be good
to know if the STS already has some of this capability).
4) A way for
the STS to associate the information passed in the RST with a higgins context /
user. There may already be something like this in the STS framework, not
sure.
5) A way to
convey the user's credentials (in this case ldap name/pw) to the STS such that
it can be used to open the Higgins
context. This can be gathered by the CardSpace selector, and I assume can
be passed securely in the RST.
6) Integration
between the STS and IdAS. Need to be able to read specific
attributes of a DigitalSubject from IdAS.
7) An IdAS
context provider (we plan to use the LDAP provider to start with).
8) A way to
turn the DigitalSubject attributes into claims for the token to be returned
(we'll assume no name or value mapping needs to occur for this app)
9) The STS
needs to wrap the produced token as a SAML assertion and return it.
It would be good
to know: a) what of the above is already done or being actively worked
on, b) who is able to and interested in collaborating on any of the
points above.
Oh yeah, we're hoping
to have this done by Dec 2. To facilitate collaboration, we will
have 15 minute meetings every Tue-Thu at 11am MDT (11am MST after Oct 29).
These will take place on the #bandit-project
IRC chat channel at irc.freenode.net.