iBeacons & Bluetooth LE

Bluetooth Low Energy (Bluetooth LE) is also known as Bluetooth Smart. It is designed to provide Bluetooth based functionality without draining the battery power of your device. Bluetooth LE is part of Bluetooth 4.0 specification. You can download the specification from Bluetooth.org. You would find three kinds of…

Prefer 32-Bit with Any CPU Platform Target - Visual Studio 2012 Enhancements

Visual Studio allows us to compile our code targeting x86 or x64 platforms by clearly specifying platform targets. We can also compile against Any CPU option. This allows the run-time to JIT the assembly in 32 or 64-bit code based on the type of process it is loaded in. Compiling an application against 32-bit would not stop it from running on a 64-bit windows platform, it would just use WOW64. We have discussed about WOW64 long back here.

In order to target an application to 32 or 64-bit, we can just specify the platform target for the start-up project in its property page. I am sure the readers, of this blog, have seen this page a lot of times. Here you seen the Any CPU target. In Visual Studio 2010 the Build tab in project's property page looks as follows:



With other various updates, Visual Studio 2012 has improved on Any CPU a little. Now selecting Any CPU allows us to further qualify our selection. Please notice Prefer-32 bit option here.



Let's see how the IL looks like. You can see that the assembly is compiled differently.



The new framework should be able to handle this option. This is why you see the option greyed out when we select any such framework including .net framework 4.0. It should be available for .net framework 4.5.



This option is only for executable type of projects(*.EXE). For all other project types as well, you should find this option greyed out.

Compiling with 32-bit Preferred
Setting the option in Visual studio causes the new compiler switch to be used for the project. The project is compiled using C# compiler (csc.exe) with switch anycpu32bitpreferred You can find further details about the compiler switch here on msdn.

CorFlags 32-bit
As we know we can set / reset 32-bit flag using CorFlags tool available with Visual Studio. Well the tool has also been updated to support this extra details for such assemblies. Now there are two flags instead. They are 32BITREQ and 32BITPREF.



We can verify the setting of flag by opening an assembly compiled with this option selected. You can see that 32BITPREF flag has been set.



Effects of Setting 32BITPREF
Now we have see how to set this flag and how it would be reflected in the generated assembly. We still haven't discussed what it actually does. Or what it tells to the host framework running the application.

The difference in setting the switch or avoiding Any CPU would make all the difference when the executable is run on a 64-bit operating system. For an application compile without the switch would run it as a 64-bit process. Setting the option would still run it as a 32-bit process even on a 64-bit operating systems. As we know, we can identify a 32-bit process in Task Manager if we find a *32 with its name in Task Manager. We should continue to see them as 32-bit process in Task Manager. As we discussed before, this is exactly how our application should run if we are compiling it with x86 platform target.



The other difference is when the executable is run on ARM Windows system. The ones compiled using Any CPU wouldn't run on an ARM machine (Advanced RISC Machine). With 32-bit preferred, they run as a 32-bit process.

WCF Security - AzMan [Windows AuthoriZation Manager]

AzMan is the short-form for Windows AuthoriZation Manager. This is one of the option for Role Based Security for enterprise level applications. AzMan provides runtime and GUI tool for managing Role-Based Access Control (RBAC) authorization policies in the form of a MMC Snap-in.

AzMan allows our systems to be divided into various scopes and operations. It allows assigning certain roles mapped to these operations. Now the application just need to determine from AzMan whether the requesting user has permissions to perform the requested operation based on the role assignment to the user. These roles can very easily be mapped to the Windows groups as well but we can also add users directly to these roles. It provides the opportunity to factor out the security logic from the applications and allows to define the authorization policies totally outside the application. It also allows to use scripts [VBScript / JScript] and allows parameter passing for more fine grained security policies. Since the authorization policies has been factored out of the application, it is very easy to assign the responsibility for managing security roles to security administrators. The GUI is based on Microsoft Management Console but it completely supports creating new GUI using the API. The MMC and related runtime libraries are available in %Windir%/System32 folder. You can see in the below image that Azman runtime and GUI are available in Windows 7 out of the box.



The purpose of this post is to see how we can use Authorization Manager to define role based security for our WCF Services. Along the way, we would add the necessary details about using AzMan but it should not be considered as a comprehensive discussion about AzMan.

It has been termed as Microsoft's Best Kept secret. Although this is supported in Windows Server 2012, there are hints that it might be discontinued for future releases. I think this is because of a better tool, Windows Identity Foundation, which I think Microsoft sees as more strategic intra and inter-orgranization role based access control. This is from MSDN:

AzMan is available for use in the following versions of Windows: Windows Server 2012, Windows 8, Windows Server 2008 R2, Windows 7, Windows Server 2008, Windows Vista, Windows Server 2003, or Windows XP. It may be altered or unavailable in subsequent versions.

But its use with Active Directory Federation Services [ADFS] provides hope for its continued support. Again from MSDN

AD FS used with Active Directory Lightweight Directory Services (AD LDS) as an identity provider for authentication and Windows Authorization Manager (AzMan) for control of access policy provides a complete solution to extending Web applications to trusted organizations.

AzMan Terminologies

• Operation: Operations are the unit for defining security. They are assigned with a unique numbers which are used by application code. We can only create operations in Developer Mode in AzMan MMC.


• Task: Operations can be grouped together in a task. A task can also be based on other tasks. We can even define VBScript / JScript business rules to be executed with the task. This allows us to defined parameterized rules. We are not using business rules in this example but you can enhance it to restrict the trader for the number of shares which can be traded in a single trade.


• Authorization Store: Authorization store is the storage of these security rules. It can simply be an xml file. Recent AzMan allows SQL Server to be defined as an authorization store. We can even use Active Directory Lightweight Directory Service or ADAM as authorization store.


• Application: An application is a conceptual concept to group scopes and operations. It allows creations of operations, grouping them into tasks, creation of roles and assigning them to these operations and tasks.


• Scope : An application can also be divided into different scopes which can have their own operations, tasks and roles assignment.


• Role: Role is an entity which can be assigned rights on operations / tasks. It is the basis of Role Based Access Control [RBAC]. We can create roles using the AzMan GUI and assign them to Domain Users / Groups. AzMan also supports dynamic roles using business rules where a user can be determined to belong to a role based on this dynamic rule. Like e.g. if a user has a Title as Manager, then he belongs to this role. A role can also be based on other fine-grained roles. These roles are assigned to individual user / groups based on the role assignment supported in AzMan GUI.
  


• Business Rule: Business rules provide dynamic nature to AzMan. Business rules can be used for parameterized operations or roles. AzMan supports business rules in VBScript and JScript. You can define timeout for execution of business rules. They can also be disabled altogether. In that case, if you have business rules defined than the AzMan API cannot be used for permission check.

Supported Repositories
Following repositories are supported to create authorization stores in Azman.

1. XML


2. AD DS: Active Directory Domain Service or ADAM [Active Directory Application Mode]


3. Microsoft SQL Server (new for Windows Vista and Windows Server 2008)

Starting AzMan
As we have discussed, AzMan is a Microsoft Management Console (MMC) based application, we can use it from MMC window. We just need to add a SnapIn to the MMC console and we should be good to go.



Now we can simply add the SnapIn using Add / Remove SnapIn feature of Microsoft Management Console [MMC].



The SnapIn should be available for selection as follows:



Alternatively, we can use the AuthorizationManager SnapIn directly. Just use AzMan.msc from the Run command.



The snapIn should appear as follows:



In the Microsoft Management console window, it should be available under Console Root:



Creating AzMan Authorization Store
In order to create authorization store, we must use AzMan in Developer Mode. We can change the selection by the following dialog available through Action -> Option menu.



Let's use the authorization manager to create an XML based authorization store. Based on the above selection of Developer Mode, we should see the following menu, let's select to create a new authorization store.



Let's make the necessary selection for creation of Xml based store. We need to specify where we want to keep the xml file for the store. We also need to make a selection of the schema. It must be remembered that 2.0 can't be downgraded to version 1.0. Additionally this cannot be accessed by clients using 1.0. But if you are just introducing AzMan in your organization, you should be making the newer schema selection.



Now let's create a new application group by right clicking the Groups folder on the left. The following dialog should appear:



It must be remembered that an application group is a group of users, computers or other security principals. There are three types of application groups: Basic Application Group, LDAP Query Application Group and Business Rule Application Group. These types are based on how the membership would be determined for the group. For an LDAP Query applicaiton group, it is determined dynamically using LDAP [Lightweight Directory Access Protocol] queries. For a Business rule application group, it is also determined dynamically but here it is determined by the scripts written in a scripting language including JScript and VBScript. It can be simpler for a basic application group where it can be determined by windows groups. It also allows to define the membership using LDAP queries.

In order to define Basic application group, let's first create a local group using Computer Management. Let's name it as Traders. At this time, we are not assigning the current windows user to the group.



Now let's use Traders group for our basic application group in Authorization Manager. We have just selected the group using Windows group selection dialog.



As we are updating the security selections, the xml store is being continously updated to include the details. Let's see how it is growing:



If we look at the contents of the store, we can realize how simply the membership is being defined. Here Trader group's SID is being used for the membership.


Creating AzMan Application
All the management of authorization store is done using the same Authorization Manager MMC SnapIn. Just right click the authorization store, you should see the option for creating an application.



Let's create an application for our WCF Service. We are naming the application as TradeExecutionApp.



Authorization Manager applications allow us to define roles, tasks and operations. Yes, they cannot be shared across the applications. This kind of make sense too. An application can have local authorization manager roles as well. The roles can be assigned to Windows / Domain groups or authorization manager groups. For authorization manager roles, the mapping can be defined for local or global authorization manager groups.



Now let's add two operations ExecuteTrade and CancelTrade. The operations should be assigned with a unique operation number. This number would be used when we would be using this policy in an application. An administrator cannot mess with operations because the application is dependent on the operation definitions. Let's create a task and assign the two operations to the newly created task as follows:



We need to assign the tasks and operations to a role to define security privileges. Authorization Manager supports creating roles. Here we are creating a role, named TradeExecutionRole and adding the task created above to the role. The roles can be assigned with operations or tasks. These roles can also be based on other roles. This can be used to define more fine grained security roles and then combine them to create roles for different related features.



These roles can be assigned to a group. Than authorization manager or a Windows / Domain group. Let's assign the role to TradeExecutors global authorization manager group.



As we have been adding these roles, tasks, operations and assignments, Windows Authorization Manager has kept updating the Xml authorization store. Let's see how it has kept the definition updated:

Using AzMan Roles for Securing Applications
This is the area which has very limited information available on the net. First of all, on my Windows 7 Ultimate machine, the folder is empty. The folder can be founded as being recommeded for referencing Microsoft.Interop.Security.AzRoles assembly. To be fair to the recommeders, I don't have a server machine where I am creating this application [http://msdn.microsoft.com/en-us/library/aa480244.aspx]



I can find the assembly can be found in the Global assembly cache.



To be exact, the Microsoft.Interop.Security.AzRoles assembly can be found in GAC_32 folder in global assembly cache.



We can browse to the GAC to add this assembly in our project.



This is actually an interop assembly for AzRolesLib.dll. We can also add the direct reference of AzRolesLib using Type Library. This would create an interop assembly in obj\Debug folder. Here we have added the reference of the library in a sample project.



Let's use AzMan based Role Based Access Control in our WCF application TradeExecutionServiceLib. Let's create a managed wrapper around the AzMan runtime libraries access as follows:



Let's create an enumeration for the operations for the application. This would help us avoiding to use the operation numbers spread across the entire code base. It must be remembered that AzMan Admin MMC doesn't allow to create / modify the operations in the Administrator mode. If we need more operations then we need to develop for implementing those operations in our applications, hence developer mode for AzMan MMC. You can see that here we have used the same operation numbers as we defined in AzMan for creation of these operations.

Now let's define an interface for checking the access on an operation for an identity. This would allow us to change the RBAC move to a different store than Windows Authorization Manager.

Now let's provide AzMan based implementation of the above interface. The type has a constructor where it requires the connection string and application name. It also has a method to implement the method checking the access rights of an IIdentity on an Operation.

Now since we have policy definition and required code completed now, we can use it in our Trade Execution Service. You can get the code from our previous post and add the above code as an existing project to the solution. You would need to add an assembly reference into our service project. It would also be required to get rid of custom Service Authorization Manager from code and App.Config.

AzMan and Enterprise Library 5
Enterprise Library - Security Application Block allows defining authorization providers. The authorization provider allows introducing security as an orthogonal pluggable concept. AuthorizationProvider.Authorize takes an IPrincipal and operation name as an input. This is similar to the requirement of AzMan. You can read further about how we can use AzMan with Security Application Block in Enterprise Library 5.0. You can even use the AzMan managed wrapper created here and use it with the Authorization Provider.

http://msdn.microsoft.com/en-us/library/ff664559(v=pandp.50).aspx

You can also find a few nuget packages provided by Microsoft and other community members in order to provide ease of development using AzMan. You can specially look at the security provider package for Enterprise Library 5.0.



Further Reading / Reference?

• Developing Federation aware applications { Windows Server 2008 } - Windows Authorization Manager:
  http://msdn.microsoft.com/en-us/library/bb897401.aspx


• Donovan Follette has a series of videos on Channel 9 discussing about AzMan:
  http://channel9.msdn.com/Blogs/donovanf/Demystified-Series-Getting-Started-with-AzMan
  

Download Code

An Introduction to Windows Identity Foundation 4.5

WIF is used to externalize the user security from applications by using claims on enterprise level.It is to incorporate security in our enterprise applications in the same way we handle security in our daily lives. Let's consider an example from real world. You go to a skydiving center to enjoy the sport. Since this is a dangerous sport, you must be 18 years of age or older to partake. How do you think they verify the age? They check your Id and determine age. If you are 18 years of age on the day, you are good to go, otherwise, go home to your parents.



Now consider how we have been implementing the similar security in our application design. In our organizations we have hundreds of applications. Each application requires some sort of authentication because security audit requires so. So if I have rights on a few applications then I have to remember the credentials of all of these applications. There is no way I could remember all these passwords, so it is possible that the user would keep the same password for all these applications or would use some easy to use password. From the enterprise architect perspective, it is difficult for me too to maintain the security logic and credentials for all of these applications. Why not we implement it the same way as the "SkyDiving Center" is verifying the age limit of the customers. They trust a government authority which issues them Id. They trust the Id as long as they have no doubts that this is actually issued by the authority. It is totally up to the State Agency how they want to verify the age. They might change it any time they want but as long as they would issue these Ids, as a business owner I don't have to change my process. As an application architect, why do I have to write security logic every time a new application is introduced. We must be creating the similar software based authorities in our environment providing security and our applications should trust these authorities for their security requirements. This is federated security. Windows Identify Foundation is to support the same.

Although we have discussed it specially in the context of government issued Id, the same scenario is true for other Ids too, including our financial Ids including credit and debit cards. Although there is a series of transactions between merchant, acquirer (merchant's bank) and issuer (customer's card issuer) for authorization, batching, clearing and funding, but there is a trust relationship between acquirer and issuer which makes financial transactions easier for us as a customer. [How credit card transactions work]

So federated security is good for the applications as there is no management of user accounts required in the applications. It is easier for enterprise security as we have a central security and authentication mechanism which can be managed more easily. This is more open to security policy changes. As a user too, this is beneficial. I am not comfortable creating user accounts in all the applications I access. This might be because I don't want to give a lot of my personal information which might be required at the user creation. Plus, I have to remember so many user names and passwords. With federated security, I don't have to do it anymore.

Let's consider the example of online shopping is Paypal. For most online shoppers, paypal offers the most secure payment experience. As a customer, we are concerned about our credit card security and don't want to share with every online merchant. So for customers, paypal offers security that we don't have to share our credit card information with the merchants. We expect Paypal to only share some useful information with merchant including name and shipping address. We can use our credit cards / bank deposit to pay PayPal but this is none of the concern of the merchant. The merchant just redirects us for payment to Paypal. We authenticate with Paypal and make payments. As soon as we make these payments we are redirected to merchant's website with the useful information for the merchant which would be used for shipping the package. As a merchant, I don't have to do any payment processing except the fact that the funds would be automatically transferred to my account balance. This is simpler than credit card processing but this model is closer to what WIF offers. When we reach a relying party, it redirects us to STS which authenticates us and provide useful tokens and we are redirected with these tokens to relying party applications. This is for Passive clients using WS-Federation Passive profiles used by browser based applications. For WS-Trust / WS-Federation Active profile based applications including smart client with web services, the model is a little bit different but the overall experience is same. This doesn't include redirection but, at design time, the client knows which STS it should use for authentication and then it just gets the issued tokens to the relying party web service application. This is certainly not the same model provided by WIF but it might make it easier to understand why tokens make sense.

What is Claim?
The whole WIF stack is based on claims. MSDN defined Claim as follows: "A Claim is a statement made by a subject about itself or another subject." Here a subject can easily be a person or an application. Since any subject can make any claim, the claims must be stamped and provided by a trusted issuer, which is called Token Issuer [Token is just a package of claims].

Going through the documentation becomes easier if we first understand the terminologies. A list of terms and their definition can be found here [http://msdn.microsoft.com/en-us/library/ee534975.aspx]. It was provided for sharepoint applications but it seems applicable for other scenarios as well.



The applications supporting claims for security, have trusted issuers which are verified. They issue tokens which can be used by the applications. These applications are called Relying Party.



So for WIF based applications, single sign on is just a matter of more than one applications supporting the same tokens provided by some issuer.



As a relying party, we trust the tokens provided by the subject as long as we could verify that they are issued by a our trust worthy Token Issuer. When the subject requests token from the Token Issuer it has to specify what relying party is it interested in. It is possible that the Token Issuer generates relying party specific tokens as the claim requirements for one application might be different than any other application.



Before subject start using the relying party features, it is asked about getting the claims from the token issuer. The mechanism for this would depend on the type of the subject. Browser based applications accesses the application and they are redirected to the token issuer. Browser based subjects are called passive. Here WS-Federation Passive profile is used where, first, user reaches to the relying party where it is redirected to token issuer. The token issuer adds the token and based on the returned response, the user is redirected to the relying party application. The relying party looks at the token and extract useful information. It might discard the message when it is found that the issuing authority is not trust worth or some required tokens are missing. Non-browser based applications including Smart client applications can have information about the token issuer at design time. This is possible because, unlike internet browsers, these are custom built client applications. So for smart client applications, even before hitting the application, the subject gets token from the token issuer and pass them to the relying parties. These clients use WS-Federation Active Profile or WS - Trust.

By using token mechanism, we have extracted the authentication and authorization logic completely outside the application. Now each application would just need the necessary tokens from the subjects which it supposed to get from token issuer. Now why and how the issuer provide the tokens to the subject? It must have to authenticate itself to the issuer. Now issuer's authentication might be based on username / password, digital certificates or any other form of authentication. This mechanism can also be changed anytime. We just need to change it at a single place i.e. the issuer side and the rest of enterprise software stack would remain unchanged. It might even use Activity Directory based domain accounts for authentication. Now active directory has no idea what claims are and how to receive user request and bless them with tokens. So Microsoft has provided another tool, called AD FS [Active Directory Federation Services 2.0]. This tool can use the authentication from Active Directory and pass tokens based on user requests. So Token issuer assigns token based on the subject's details as provided by an Identity Provider.



So the token issuer wouldn't be just providing you any tokens. First, it must have to authenticate the subject. For a simple scenario we can use ADFS 2.0 as the available Security Token Service. This can use Active Directory based accounts for authentication. It is also possible that the identified STS redirects the subject to some other STS where it can be authenticated based on other STS's identity providers. We should be able to configure this on STS level withouth making any changes to the relying party applications. This is specially useful under two scenarios:

1. Providing federated security for online applications using global identity providers. This might include public ones including Google and Microsoft Live.


2. Company mergers and acquisitions where applications would get authenticated from their enterprise STS. If Company A and Company B merges, then for company A's users to access the applications originally provided for company B's users is just a matter of configuring their STS's to trust each others. Now when company B's user accesses the application to company A's applications, it would be redirected to company A's STS first. Company A's STS would look at the user and figure out this is company B's subject so it must be redirected to company B's STS where it can be authenticated using the authentication mechanism of company B's STS.


3. Providing subjects access to the relying party applications from outside the organization's boundaries. Since Active directory is behind the firewall, the subjects cannot be authenticate using the domain accounts directly. Here Microsoft Azure Access Control Service [ACS] can be used. Now user gets the claims package by redirecting between ACS in the cloud and company's STS authenticating using the domain's account.

Active & Passive Security Token Services
WIF also support building custom STS supporting WS-Trust scenario. These are called Active STS. The STS supporting WS-Federation are called Passive STS. They are used for web-browser based clients.

Required Tools for Developing WIF based Applications
For development in Visual Studio 2010 and .net framework 4.0, we need to use Windows Identity Foundation SDK. This provides the necessary API to develop Identity aware applications and services. It also adds the required features in Visual Studio 2010 for ease of development. [Download Windows Identity Foundation SDK]



Since .net framework 4.5 has in-built support for Identity. The API support is already available. We still need to add "Identity & Access Tool" extension in Visual Studio 2012. This can be downloaded from Visual Studio Gallery.



As we know we can add extension directly from Visual Studio. Just search for "Identity and Access Tool" in Extensions and Updates window available as Tools -> Extensions and Updates.



The package has known conflict with other extensions but it seems that people has complained about different extensions. I noticed the following failure when I restarted Visual Studio after installation of the extension.



The Activity Log has the following error.

If you notice this then just uninstall the extension and disable all other extensions. Now you can install the Identity and Access Tool Extension and restart your Visual Studio. Once started you can enable all other extension. I haven't noticed the same failure when I restarted my Visual Studio again.

Microsoft Federation Identity Model
There are three components to Microsoft's federation Identity Model:

1. Active Directory Federation Services (ADFS) 2.0
2. Windows Azure Access Control Services (ACS)
3. Windows Identity Foundation

WIF 3.5 and WIF 4.5
The version number corresponds to the .net frameowork version WIF was released for. The first version was released as a separate download for .net framework 3.5 sp1. With .net framework 4.5, it is called WIF 4.5. Now this is integrated within .net framework 4.5. Applications written with WIF 3.5 need to be migrated to WIF 4.5.

WIF API
WIF types are spanned across the following assemblies:

1. mscorlib
2. System.IdentityModel
3. System.IdentityModel.Services
4. System.ServiceModel

The types are spanned across the following namespaces:

1. System.Security.Claims
2. several System.IdentityModel namespaces
3. System.ServiceModel.Security

Before .net framework 4.5, RolePrinciple, WindowsPrincipal and GenericPrincipal were all inheriting from System.Object.



Similarly the hierarchy of Identity(s) has been updated as follows:


Here FormsIdentity is from System.Web assembly. Further details about the API can be found here [ http://msdn.microsoft.com/en-us/library/jj729788.aspx]

Adopting WIF
As a business enterprise, we should never be in a business of writing STS. We can directly use ADFS 2.0 if we our applications are only available for intranet access. In case, we need to provide access from outside the application boundaries, we can start using Azure ACS. We still need to write applications which are claims aware (relying parties). We can configure the STS to provide the required tokens by relying parties which can also be based on the individual applications. For authentication, we can use Active Directory based domain authentication. I would recommend picking up an application where you provide the security authorization based on Domain Groups. From the code, get the list of authorizations performed based on the windows accounts. Now agree on converting them to be based on some claims instead. Now introduce STS and create the same tokens based on the same windows domain groups based on user login information. Configure the application and STS to trust each other. Now the application is cleaner as it has no hard-coded logic based on user's domain groups. Move applications one-by-one to use claims. Try to use the same claims as much as possible with the idea of introducing intra-organization universal claims.

Identity Developer Training Kit
In order to make learning easier for developers, Microsoft has provided a developers training kit. This can be obtained from Microsoft's download page [Download Training Kit]. The kit is available for both Visual Studio 2010 and Visual Studio 2012.



Identity Training Course
Microsoft has other offline training courses for the identity development for different scenarios. All of these trainings are free. The trainings can be accessed from here [ http://msdn.microsoft.com/en-us/evalcenter/gg557929]. The trainings are available to for websites, web services, Windows Azure and Silverlight based application development. There are following units available for the course: