+1 on M1 freeze and do a newer version for M2. that keeps the apps simpler and provides choices to users to test whichever features they like.
-----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Sunday, July 19, 2009 9:47 PM To: [email protected] Subject: Re: Feature options and versioning [was - Suggestion: mutual certificates viz 3rd party identity] 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 > >
