Harold, I think we are on the same page with us freezing milestone versions and leaving them available for a reasonable length of time (I would like "forever" but realize that there is some storage cost in the SVN repository). Having the setup instructions available will allow anyone who wants to implement a version to do so and if we can also have endpoints for the current and at least N-1 version of the project hosted at the Apache foundation it could really lower the barrier for the interoperability testing.
Scott Golightly -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Sunday, July 19, 2009 10:45 PM To: [email protected] Subject: Re: Suggestion: mutual certificates viz 3rd party identity 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 >
