It is my intention that we continue to use the configuration system (although when I started to incorporate it the feature wasn't complete and I ran into some problems). I am getting back around to looking at the configuration system. I also see the advantage of a release that has the current changes without the need for a STS. This would give a stable implementation of the configuration system without having to use token based security.
Scott Golightly -----Original Message----- From: Drew Baird [mailto:drew...@yahoo.com] Sent: Wednesday, July 29, 2009 11:14 PM To: stonehenge-dev@incubator.apache.org Subject: Re: Suggestion: mutual certificates viz 3rd party identity We need an M1.5 that has all the good stuff Ben and Avantika have added before we move on to Claim/Metro et al My two cents. Drew ________________________________ From: Ben Dewey <ben.de...@26ny.com> To: "stonehenge-dev@incubator.apache.org" <stonehenge-dev@incubator.apache.org> Sent: Wednesday, July 29, 2009 8:53:18 PM 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 >
