After exploring security topics based on requirements (or federated security models). I have met many examples that use CardSpace as an example. The main article I read gave a really excellent explanation for this issue, was a Microsoft PDF in a framework called Zermatt .
The claims-based security architecture I'm looking at is equivalent to the STS implementation. An authentication broker combined with an STS authorization broker. So when I create a new service, all I have to do is make sure that the service will accept applications issued by authorization broker. And, as indicated in this article, an authorization broker accepts only claims issued by an authentication broker.
With this setting, at any time when the client tries to use the new service, it must be authenticated using the Authentication Broker (issuing an authenticated application) , and then logged in using an Authorized Broker (issuing an authorized request) .
It's all fine and dandy, and the architecture is clear, but I don't see exactly how to implement STS. As I mentioned, most (if not all) examples on the Internet show how to use CardSpace, but this does not work when you have a database that supports your authentication scheme.
Scenario example
alt text http://img512.imageshack.us/img512/8329/claimsbasedsecurityza6.jpg
wcf-security saml federated-identity sts-securitytokenservice geneva-framework
nyxtom
source share