I rarely use this space except to satisfy [[WP:BLP]] citability requirements, but somehow it keeps getting more traffic than it really should.
If you're actually interested in my posts to the Internet on a day-to-day mundane basis, check out facebook.com/felon/ or twitter.com/6
Cheers!
Suppose you don't want to modify any of your projects in your solution. Create a new msbuild.proj file and run msbuild on this with your configuration. Instantly you have all your assembly info files updated for any project in a directory.
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="build">
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Import Project="$(MSBuildExtensionsPath)\SvnTools.Targets\SvnTools.Tasks.VersionManagement.Tasks" />
<Target Name="build">
<CreateItem Include="/Properties/AssemblyInfo.cs;/AssemblyInfo.cs">
<Output TaskParameter="Include" ItemName="AssemblyInfoFiles" />
</CreateItem>
<UpdateVersion AssemblyInfoFiles="@(AssemblyInfoFiles)" />
<MSBuild Projects="MySolution.sln" Properties="Configuration=Debug" />
<RevertVersionChange AssemblyInfoFiles="@(AssemblyInfoFiles)" />
</Target>
</Project>
http://svnversiontasks.codeplex.com
There is now an open source release on CodePlex for a subversion based assembly version management library that leverages MSBuild Tasks for automation. What this provides is a way for you to integrate version management on your Visual Studio Projects and automatically ensure that the SVN Revision number is attached to the assembly version.
For instance, if you commit and have a clean working SVN directory on revision 1234 your version number on your assembly file will be (once you build the project):
1.0.0.1234
The MSBuild tasks will ensure that the version is updated before compiling and then revert that change in the assembly info file. It will always maintain the major and minor numbers set by the original source but it will update the build and revision number using the format:
Major.Minor.(Revision Number Digits Length - 4 or 0).(Last 4 Digits of Revision Number)
There is a great tutorial on generating certificates below using both OpenSSL and the makecert methods.
http://www.codeplex.com/wikipage?ProjectName=webserver&title=HTTPS
If you haven't read my previous articles on security, please take the time to read through each of them to give yourself a headstart into what concepts are being implemented here. Windows Identity Foundation (Geneva) provides a very simplistic view of the world of Security Token Services and as a result, it is very useful to understand how WS-Trust, Federation and even basic security works in our applications.
* IPrincipal, IIdentity and Claims (threading, WIF, Asp.NET Forms Authentication)
* Overview on Digital Signatures (Signing, Encrypting, Hashing)
* Windows Identity Foundation (Overview, WS-Trust, Federation)
Though, don't take my articles to be the end all in what you read. Reading is important and you should take time to dive into the topics in detail to get a better grasp.
Setting up the Security Token Service
First, download and install the Windows Identity Foundation (Geneva Framework)
Next, setup a new project in Visual Studio, preferrably a Console Application to demonstrate.
Add a reference to Microsoft.IdentityModel and System.ServiceModel, as well as System.IdentityModel, then create a new class for the Security Token Service, I will call mine HealthCenter. Inherit this class from SecurityTokenService and implement the abstract class.
public class HealthCenter : SecurityTokenService
{
public HealthCenter(SecurityTokenServiceConfiguration config) : base(config) { }
protected override IClaimsIdentity GetOutputClaimsIdentity(IClaimsPrincipal principal, RequestSecurityToken request, Scope scope)
{
throw new NotImplementedException();
}
protected override Scope GetScope(IClaimsPrincipal principal, RequestSecurityToken request)
{
throw new NotImplementedException();
}
}
You'll notice that the two methods GetOutputClaimsIdentity and GetScope are the only methods we need to setup in the service. The configuration provided is another section that you must include with the constructor.
GetScope
At this point it should be noted that and client connecting the the STS will have already passed authentication. This means authentication can be configured to use any method you want to see fit within your ecosystem. The request security token (RST) provided will tell this method who the relying party is as well as additional claim requests. This method performs the following responsibilities:
* Validate the relying party to determine if the request is on behalf of a trusted source
* Load the signing credentials for the STS (typically a certificate)
* Load the encrypting credentials based on relying party it is for (or use a generic one)
* Create a new scope for the RST with the signing and encrypting credentials
For simplicity let's adjust this to handle a specific relying party with a few specific credentials.
protected override Scope GetScope(IClaimsPrincipal principal, RequestSecurityToken request)
{
string uri = request.AppliesTo.Uri.AbsoluteUri;
if (uri == "net.tcp://localhost:2314/HealthRecords/")
{
SigningCredentials signing = new X509SigningCredentials(GetSigningCertificate());
EncryptingCredentials encrypting = new X509EncryptingCredentials(GetEncryptingCredentials(uri));
Scope rstScope = new Scope(uri, signing, encrypting);
return rstScope;
}
else
throw new InvalidRequestException("The request must apply to a trusted relying party.");
}
As recommended, we are using X509 based Signing and Encrypting credentials. This means we need to load an X509Certificate2 from the certificate store or from disk. Take a look at my previous article on how to load certificates from the certificate store.
The only difference between the signing and encrypting certificate is that the encrypting certificate is based on the applies to address. If we had setup a configuration item for this or someway of linking the address to a certificate then that part would be resolved.
GetOutputClaimsIdentity
Now that the scope has been defined for the request security token response (RSTR), all that is left are the claims about the client and any requested or related claims for the relying party. We will need to create the actual claims identity based on the request. You have the option of simply returning the same claims or injecting new ones based on the Request Claims. Take a look at the sample provided in the installation samples for more.
In .NET Security there are two interfaces that identify the context of permissions through authentication and authorization. These two interfaces provide a mechanism for implicating authorized code and more important application functionality by being directly embed into the app domain running thread.
Much of the functionality in Web Applications uses this behind the scenes when dealing with authorization through an implementation of these interfaces and can be managed through configuration through the standard authentication schemes. This is apparent in the way Asp.NET handles forms authentication and how it works with user's threads.
Asp.NET Forms Authentication and Thread.CurrentPrincipal
Once a user authenticates in an Asp.NET web site, the application will create a forms authentication ticket based on the user parameters and website cookie expiration settings. This ticket is then stored in an Http cookie and sent back to the client on the correct cookie path so that can it be leveraged each time the client posts to the web site. On the application authenticate request event, the website will have the validated identity injected into the thread's current principle and page.user objects.
Aside from Asp.NET, any application within an AppDomain has the ability to take advantage of code access security by leveraging the Thread.CurrentPrincipal object. There are even methods of injecting your own on the AppDomain.
Windows Identity Foundation and the Claims
In Windows Identity Foundation (Geneva) a concept of the ClaimsIdentity is introduced to attach verified claims issued by a security token service. The claims themselves can be any number of specialized properties about an identity. A claim having a ClaimType, Issuer, OriginalIssuer, bag of Properties, IClaimsIdentity Subject, Value and a ValueType.
The IClaimsIdentity itself is attached with the IClaimsPrincipal whereby both are attached to a thread upon the relying party application receiving a trusted issued token from an STS. This process, in a web application, is done in the manner of creating the forms authentication ticket as it did previously but specifically for the claims identity in context.
Nevertheless, the introduction of Windows Identity Foundation (Geneva) provides an opportunity to implement code access security with a focus on claims with certain values. The permissions themselves could be implemented as attributes that ensure that the identity in context has a claim with a certain condition, on top of roles based security.
A digital signature is nothing more than an asymmetric cryptographic message who's use is primarily assuring authenticity of the intended message to relying parties. The process of digitally signing data involves:
1) Creating a hash value of the data
2) Encrypting the hash value using a signing credential's private key thus generating a signature
3) Attaching the signature to the end of the data itself.
The intended party of the signed data can then verify the signature by decrypting the signature part of the data with the signing credential's public key. The decrypted hash value simply needs to be compared against a generated hash value of the rest of the data sent. If the two hash values match then the signature is valid. The trust relationship that exists between the intended party and the signing party is based solely on the trust of the public key credentials. These credentials are usually, 99% of the time, in the form of certificates.
Security can be further employed through a relying party encryption approach (similar to Security Token Services). This is where the signing party encrypts the full document (including the signature) with the relying party's public key credentials. The relying party (intended party) can then decrypt the full document with its private key and proceed to validate the signature. This approach assumes that the trust relationship is established by an exchange of public key credentials from both parties.
You can read more about digital signatures on Wikipedia below:
If you aren't familiar with the new Windows Identity Foundation (formally known as the Microsoft Geneva Framework), then I suggest giving it a try. Windows Identity Foundation provides a foundation for creating security token services and single sign-on solutions without all the pain of handling SAML tokens and implementing the WS-Trust protocol.
There is, however, a somewhat steep learning curve to all the terminology in the world of SSO, Federation and Security Token Services. A series of guidelines are available on the MSDN.
WS-Trust and WS-Federation
To fully understand how a single-sign on website works in the federated world of websites, it might help to get a glimse of understanding in WS-Trust.
"WS-Trust (or the Web Service Trust Language) is a WS-* specification and OASIS standard that provides extensions to WS-Security dealing with issuing, renewing, validating and expiring security tokens. It also provides a way to address the presence of and broker trust relationships between participants of the secure message exchange."
These participants are typically known to be the user, the issuing authority (STS) and a relying party of some sort. A relying party in most cases is another web application or another application. Here's an example of this in action:
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
1) A user wants to use Xbox Account Management but must login first
2) Xbox (relying party) redirects the user to Windows Live Login (STS/Issuing Authority)
3) Windows Live Login has the user enter their credentials first before continuing the request
4) The credentials are verified against the Windows Live store and used to create an identity token. The identity token is signed by the issuing authority's signing credentials.
5) The request shows that it the user is coming from the relying party Xbox.com. The STS looks up to determine if the relying party is fully trusted and if so, the STS will include additional claims on the user's identity token based on this new detail.
6) The STS will then encrypt the issued token based on the relying party Xbox. (This is usually done per relying party but can sometimes use the same encrypting credentials across all trusted relying parties)
7) The STS returns the now issued token back to the Windows Live site which will redirect back to Xbox posting the token to the Xbox site.
8) Xbox will decrypt the token from the post verify that the signature is from a trusted issuing authority (STS) and more specifically from Windows Live (perhaps the only trusted issuing authority). After verifying the token's signature, the site will set the token on the thread and create a session token for the site as the user is now authenticated.
As you can see the WS-Trust model is the part that fully involves the issuing authority and security token service. WS-Federation is the process of properly redirecting the user and requests appropriately with a standardized query and post format. The "token" itself that is posted and moved about is known as the SAML token.
Within WS-Trust the standard way to communicate with the STS is through a request security token. The request security token instructs the STS who the token is being issued on behalf (the relying party), what form the token should be formatted in and what claims are being requested about the user. The STS will return in the form a request security token response. The response itself amounts to the SAML token but is also known to be the claims identity.
Unlike traditional web services, WCF provides many different ways to communicate with a service. These are primarily driven by the bindings as configured via the application configuration file or the web configuration file. Aside from the contracts, the binding heavily depends on what you are trying to expose and how applications will leverage it.
basicHttpBinding: use for supporting legacy clients that expect ASMX service, does not implement security by default, defaults to no credentials just like ASMX services
wsHttpBinding: WS-Reliable Messaging, WS-Security, http transport, text/xml encoding, mesage security with windows authentication by default
ws2007HttpBinding: WS-Reliable Messaging, WS-Security, http transport, text/xml encoding, binding similar to wsHttpBinding but uses OASIS, message security with windows authentication by default
netTcpBinding: optimized for cross-machine communication, generates runtime communication stack with transport security and windows authentication by default, tcp protocol, binary message encoding, must be hosted in Windows Service or IIS7 via Windows Service Activation
netNamedPipeBinding: optimized for on-machine cross process communication, generates runtime communication stack by default, WS-Reliable Messaging, transport security, named pipes for message delivery, binary message encoding, not secured by default, must be hostedin Windows Service or IIS7 via Windows Service Activation
netMsmqBinding: queued binding for cross-machine communication, used for disconnected queuing, queuing provided by MSMQ as transport, supports disconnected operations, failure isolation, load leveling, use for when client and service do not both have to be online at the same time, must be hosted in Windows Service or IIS7 via Window Service Activation
wsFederationHttpBinding: federated security, used in implementation of federation, wcf implements federation over message and mixed mode security but not over transport security, must use http protocol as transport
ws2007FederationHttpBinding: similar to wsFederationHttpBinding but uses OASIS. Commonly used in integrating with STS services.
wsDualHttpBinding: duplex service contracts over http binding through SOAP, similar to wsHttpBinding but leveraged for duplex services. Does not allow hosting in IIS5 or IIS6, host in Windows Service or IIS7.
customBinding: Describes a full binding channel with elements through protocol binding elements, message encoding binding elements, transport security binding elements and transport binding elements.
Protocol Binding Elements: Transaction Flow, Reliable Messaging, Security
Message Encoding Binding Elements: Text, MTOM, Binary
Transport Security Binding Elements: Windows, SSL
Transport Binding Elements: HTTP, HTTPS, TCP, Named Pipes, MSMQTransport, MSMQIntegration, P2P
As I mentioned each of these bindings has there own purpose. You can see that from the custom binding you can create your own configuration for how clients and services communicate with the behavior of the exposed service. You'll find that contracts and code written will, for the most part, never change when it comes to WCF. There's no reason not to create web services through WCF anymore since you can leverage any kind of communication protocol you want and throttle, secure, integrate with any system your project needs.
