Kent Brown wrote:
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.
Ben Dewey wrote:
But, would the idea be to have a M1.1 release or a Certs branch with the latest?
What if something needs to be changed to M1.1 after the fact, but it's
essentially frozen/deprecated? (ie. Bug fix, a WS standard changes, .NET 4.0
release)
It seems that M1 still provides value - a simple mutual certificates example
that does not have additional download and setup steps (i.e., OpenSSO or Geneva
framework).
It would be nice to see M1 at least updated with the refactoring work and the
better configuration.
Regarding how to manage M1 - not sure.
Regards,
H
