Hello Scott,
The more I thought about it after sending my message I realized that what I
suggested would make it easier to setup the non-claims version using the same
code as the claims version but would make the shared code too complex.
It seems that a manageable solution, if I understand you correctly, it to have
M1 available (the non-claims version) and also have M2 (the claims version)
available.
So people can still take small steps first using M1 then switch to M2, which
would have many of the same steps also some additional ones, and continue.
That seems reasonable. The main CON with that method is duplicate code between
branches, but that seems like something that could be handled.
Please let me know if we are on the same page.
Thanks,
Harold
ps: yes, having Apache host endpoints of M1 and M2 would be good
Scott Golightly wrote:
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: [email protected] [mailto:[email protected]]
Sent: Tuesday, July 14, 2009 4:25 PM
To: [email protected]
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
