the advents with nyxtom

Easier Svn Version Tasks

2009-11-20T17:46:46Z

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.

http://svnversiontasks.codeplex.com

Read and post comments | Send to a friend

Svn Version Tasks

2009-11-04T21:10:37Z

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)

Check it out by going to the link below:

http://svnversiontasks.codeplex.com/

Read and post comments | Send to a friend

Generating a self-signed certificate

2009-10-20T20:21:21Z

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

Read and post comments | Send to a friend

Security Token Service with WIF

2009-10-14T22:56:59Z

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)

http://nyxtom.vox.com/library/post/iprinciple-iidentity-and-claims.html

* Overview on Digital Signatures (Signing, Encrypting, Hashing)

http://nyxtom.vox.com/library/post/digital-signatures.html

* Windows Identity Foundation (Overview, WS-Trust, Federation)

http://nyxtom.vox.com/library/post/windows-identity-foundation-formally-microsoft-geneva-framework.html

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)

http://msdn.microsoft.com/en-us/security/aa570351.aspx

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.

http://nyxtom.vox.com/library/post/working-with-x509certificates-keysets-and-the-certificate-store.html

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.

Read and post comments | Send to a friend

IPrinciple, IIdentity and Claims

2009-10-13T23:52:31Z

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.

http://www.informit.com/articles/article.aspx?p=102217&seqNum=2

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.

Read and post comments | Send to a friend

Digital Signatures

2009-10-13T19:00:01Z

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:

http://en.wikipedia.org/wiki/Digital_signature

Read and post comments | Send to a friend

Windows Identity Foundation (Geneva Framework)

2009-10-13T18:37:41Z

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.

http://msdn.microsoft.com/en-us/security/aa570351.aspx

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."
http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html

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.

Read and post comments | Send to a friend

WCF Bindings

2009-10-12T19:47:16Z

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.

Read and post comments | Send to a friend

.NET 1.1 in Visual Studio 2008

2009-08-08T05:53:23Z

Everyone who regrets installing Visual Studio 2003 can take pleasure in knowing there is an alternative. There is an MSBuild Extension called ‘MSBee’ that was built to manage building applications using Visual Studio 2005 projects that target .NET 1.1. Moving forward to use Visual Studio 2008, there is an extension to that called CrossCompile.CSharp.targets and CrossCompile.CSharpWeb.targets

Referencing article: http://devlicio.us/blogs/ziemowit_skowronski/archive/2008/08/22/working-with-net-1-1-in-visual-studio-2008-and-team-server.aspx

From that, it is possible to create a Visual Studio 2008 Project and ensure that it compiles directly to .NET 1.1 Assemblies.

Setup:

Download MSBee and install it (make sure you install the .NET Framework 1.1 and the .NET Framework 1.1 SDK): http://www.codeplex.com/MSBee

Download CrossCompile and export the targets to your %Program Files%\MSBuild directory.

http://www.gl-net.org.uk/Files/CrossCompile.zip

Take a look at that article on how to take an existing project and ensure that you can convert it for Visual Studio 2008.

New Class Library Project Templates

Or if you happen to need a new project, I have created a Visual Studio Templates just for that: http://nyxtom.googlepages.com/ClassLibrary-Net.1.1.zip

Note about adding additional references: Your project is set to .NET 2.0 so by default it any additional references added are only going to show as 2.0 References. To fix this, (say you add System.Web.Services) unload the project, edit the .csproj file and find the section that indicates a ‘HintPath’. You can either specify the .NET 1.1 Framework HintPath or delete the HintPath altogether. Without the hint paths, Visual Studio will assume .NET 2.0 and thus give you the ability to write 2.0 code; however any 2.0 based code you do write will cause a compiler error as it isn’t supported by the .NET 1.1 CSC ran by CrossCompile and MSBee.

Enjoy J

Read and post comments | Send to a friend

Automating your certificate installation

2009-04-28T07:23:39Z

When was the last time you decided you needed to deploy a product of yours. How often is it that you run into a situation where configuration and the manual to installation of your projects becomes a royal pain in the neck? Well, for most, maybe not all that often, but for the few in the corporate world - this may happen all too often.

It's nice having ClickOnce features to do a lot of the work for us. But unfortunately ClickOnce can't handle all the nitty gritty components we would like it to.

Tool Number 1: Automated Installation of Certificates into the Certificate Store

You can use the CertMgr.exe to automate the use of importing certificates into a certificate store. The CertMgr comes with the .NET Framework SDK Tools and is typically located in %ProgramFiles% \Microsoft SDKs\ Windows\ v6.0A\bin\certmgr.exe. Executing the following will import a certificate into the localmachine personal certificate store.

certmgr /add MyCertificate.pfx /r LocalMachine /s My -all

certmgr /del /n "My CertSubject Name" /r LocalMachine /s My -c

This makes it especially useful when you are working with services that require use of certificates. Believe it's a pain :/

Unfortunately, this method will not work for certificates that are password protected. For that, you can write up a little C# program that will take care of those password protected situations.

using System;
using System.Security.Cryptography.X509Certificates;

namespace AddCert
{
   class Program
   {
   static void Main(string[] args)
   {
   if (args.Length != 7 && args.Length != 5)
   Console.WriteLine("Usage: addcert cert.pfx /r LocalMachine /s My /pass mypass");

   string path = args[0];
   StoreLocation sl = (StoreLocation)Enum.Parse(typeof(StoreLocation), args[2]);
   StoreName sn = (StoreName)Enum.Parse(typeof(StoreName), args[4]);

   X509Store store = new X509Store(sn, sl);
   store.Open(OpenFlags.ReadWrite);
   if (args.Length == 5)
   store.Add(new X509Certificate2(path));
   else if (args.Length == 7)
   store.Add(new X509Certificate2(path, args[6]));
   store.Close();
   }
   }
}

To use that, you can simply compile to the exe, and run that from a batch file like anything else you can do.

Enjoy :)

Read and post comments | Send to a friend