I didn't realize the Claims version has Certs between BS/OPS. I was more concerned that the functionality would be lost. I'm all for NOT complicating the releases, as long as users can have downloadable samples of the different scenarios.
I'm okay with forcing users to implement the entire ST environment, claims and all, to get up and running (i.e. no certs code freeze). If we go the route of a code freeze though, we should look at trying to implement the config pieces. -Ben Dewey -----Original Message----- From: Kent Brown [mailto:kent.br...@microsoft.com] Sent: Thursday, July 30, 2009 12:33 PM To: stonehenge-dev@incubator.apache.org Subject: RE: Suggestion: mutual certificates viz 3rd party identity The way I understand how things are shaping up with respect to Claims-based security we will use passive WS-Federation for the web app, then use active STS with WS-Trust 1.4 between the web app and BS, and then will use the existing WS-Security techniques using certificates between BS and OPS. In fact I would like to add a couple of new security options to the mix between BS and OPS. So in the end, the only reason to use the M1 stack may be if you think it's too hard to set up the claims-based security. I have confidence we'll get the setup right for the Stonehenge code. The only thing that might be hard to set up is the passive STS. The .NET implementation will use .NET code (it'll be built using Geneva Framework) and so should not be a burden to set up (meaning we can script most of what will be necessary). And from what I understand Sun's product for hosting the passive STS (OpenSSO) was fairly straightforward for the ThoughWorks team (who were new to it) to set up. I'm not opposed to branching and taking some of the config goodness back to the "M1" version, but I'm wondering if it will really be necessary if we do M2 right. -----Original Message----- From: Ben Dewey [mailto:ben.de...@26ny.com] Sent: Wednesday, July 29, 2009 8:53 PM To: 'stonehenge-dev@incubator.apache.org' Subject: RE: Suggestion: mutual certificates viz 3rd party identity I'm not sure if I completely understand you guys, but I'm a little bit concerned that if we freeze M1 as our "Certificate" version we'll be missing out on all the recent configuration changes and the contributions from Metro. Will this technique still allow for these new features to be used? I know it may be taboo, but would branching the code be an option. -Ben Dewey -----Original Message----- From: Scott Golightly [mailto:scott_goligh...@hotmail.com] Sent: Monday, July 20, 2009 1:12 PM To: stonehenge-dev@incubator.apache.org Subject: RE: Suggestion: mutual certificates viz 3rd party identity 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: harold.c...@sun.com [mailto:harold.c...@sun.com] Sent: Sunday, July 19, 2009 10:45 PM To: stonehenge-dev@incubator.apache.org 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: 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 >