Hello Kent, I agree on the M1 freeze then a M2 version also.
It would be good to encourage new stacks to do both versions. Thanks, H Kent Brown wrote:
This is a very important thing for us to get consensus on. I see value in the option Harold suggests of making things configurable so consumers of Stonehenge can easily get the simpler stuff up and running and then set up the claims-based or other "advanced" features if they want them. However, I think the configuration to do that in one code base sometimes causes a different kind of complexity in the code. (We are currently simplifying the .NET implementation to take out this type of code.) I lean towards freezing the M1 implementation as the no WS-Trust/Claims approach, and having the M2 release refactored cleanly as necessary to reflect good use of WS-Trust. I guess the downside to that is it requires new stacks that join Stonehenge to potentially implement multiple versions of the app. For example, with Sun Metro, should you just implement the M2 version, or should you complete, test, and freeze an M1 version, and then also do an M2 version? In Sun's case you will do both since you started before M2 was completely defined, but what would another stack choose if they come in after M2 is released? I think it's best to leave that as an option for each participant to support whichever version(s) they see value in. We just need a way to go back and add a newly released implementation as part of a past release. Kent -----Original Message----- From: Scott Golightly [mailto:[email protected]] Sent: Wednesday, July 15, 2009 1:55 PM To: [email protected] Subject: RE: Suggestion: mutual certificates viz 3rd party identity 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
