Harold,
We have the M1 milestone version that looks up the user name and password in
the database and passes the profileID in a cookie. That version would be
available for people to download and start working with. I thought about
having a configuration option for database lookup or for claims
authentication. I decided to not propose that as it would cause a lot of
extra code and if statements that would make the code harder to read.
We had a suggestion to have Apache host endpoints for the major releases so
people interested in the samples could download and compile one
implementation of the code and show interoperability with the endpoints
hosted in the cloud. This should address some of the complexity with setup.
As far as having the existing authentication mechanism carried forward
because it is a useful scenario in its own right I don't disagree with that
statement but I still think it would make the code harder to read.

Scott Golightly

-----Original Message-----
From: harold.c...@sun.com [mailto:harold.c...@sun.com] 
Sent: Tuesday, July 14, 2009 4:25 PM
To: stonehenge-dev@incubator.apache.org
Subject: Suggestion: mutual certificates viz 3rd party identity

I understand that the StockTrader is moving towards claim-based identity,
with 
that identity provided by a service (e.g., Metro STS framework, Geneva 
Framework).  Definitely a good idea.

However, it would be good to keep the existing version of Stonehenge (I
assume 
it uses mutual certs?) because:
- one less thing to setup
- it is a useful scenario in its own right

It seems that most of the code between the two security versions could be 
shared, right?

That way someone new to the example could download just ONE implementation
and 
get the mutual certs version working first.  Then, as they gained experience
and 
confidence they could move on to trying real interop and/or identity
providers.

In other words, make it easy for people to get up and running in small steps

instead of a big bang.

Regards,
Harold

Reply via email to