I've got a simple client-server application based on TcpClient/TcpListener and SslStream. Clients can authenticate themselves to the server using a X509Certificate or by sending a user name and password after the SslStream has been established.
WCF makes use of the System.IdentityModel namespace for authentication purposes, but apparently that can be used in arbitrary applications--which sounds interesting. Information on how to do this is sparse though (or my Google foo is weak today).
So, my question is: What do I need to do to integrate System.IdentityModel with my application? I'm not sure if I need all that ClaimSet stuff, but it would be nice if users could log in just using their Windows account or any other provided authentication mechanism. (Unfortunately I can't just switch to WCF but have to use the custom protocol, although I can make some changes to it if necessary.)
My Google foo was indeed weak. The answer is right behind the link in my question. So here are a couple of links to this blog in case somebody has the same question eventually.
First, you should try to understand "that claim set stuff":
- Claims
- Claim Sets
- Inspecting Claim Sets
- Windows and X509Certificate Claim Sets
- Typical Operations on Claim Sets
Then, you need to know where claim sets come from:
- Authorization Policies, Context and Claims Transformation
- Claims Transformation in WCF
- Authorization Context and Claims Transformation outside of WCF
Armed with this knowledge, it actually becomes quite simple.
If I understand it correctly, the basic workflow would be something like this:
- Client creates a
SecurityToken
using aSecurityTokenProvider
- Client serializes the
SecurityToken
using aSecurityTokenSerializer
- Server deserializes the
SecurityToken
using aSecurityTokenSerializer
- Server creates
IAuthorizationPolicy
s using aSecurityTokenAuthenticator
- Server creates
AuthorizationContext
fromIAuthorizationPolicy
s - Done
Example:
// Create the SecurityTokenProvider
var p = new UserNameSecurityTokenProvider("username", "password");
// Get the SecurityToken from the SecurityTokenProvider
var t = p.GetToken(TimeSpan.FromSeconds(1.0)) as UserNameSecurityToken;
// ... transmit SecurityToken to server ...
// Create the SecurityTokenAuthenticator
var a = new CustomUserNameSecurityTokenAuthenticator(
UserNamePasswordValidator.None);
// Create IAuthorizationPolicies from SecurityToken
var i = a.ValidateToken(t);
// Create AuthorizationContext from IAuthorizationPolicies
var c = AuthorizationContext.CreateDefaultAuthorizationContext(i);
ShowClaims(c.ClaimSets);
For X509SecurityToken
s use a X509SecurityTokenProvider
/Authenticator
. For WindowsSecurityToken
s there's a WindowsSecurityTokenAuthenticator
but not a provider; instead, use the WindowsSecurityToken
constructor:
var t = new WindowsSecurityToken(WindowsIdentity.GetCurrent());
This works quite well. The only thing I omitted so far above is the token serialization. There is a SecurityTokenSerializer
class which has one implementation in the .NET framework: the WSSecurityTokenSerializer
class which comes with WCF.
Serializing UserNameSecurityToken
s and X509SecurityToken
s works like a charm (haven't tried deserialization), but WindowsSecurityToken
s are apparently not supported by the serializer. This leaves me with the two authentication methods that I already have (certificates and username/password) and, as I didn't want that AuthorizationContext
anyway, I'll stick with what I have :)
I don't have the reputation to post a comment to the existing solution, but I'd like to post the new URLs to the blogs listed in the solution, since those don't work anymore. If someone can change this to a comment, I'd be much obliged.
来源:https://stackoverflow.com/questions/646395/how-to-use-system-identitymodel-in-own-client-server-application