The Microsoft Security Intelligence Report for 2010 was released not too long ago. It is a report on the threat landscape seen across 600 million systems worldwide.
This report has a summary for quite a number of countries (170 and counting), and Canada is in the list. Here are the stats they found:
Microsoft detected malware on 4.2 of every 1,000 computers scanned in Canada in 4Q10 (a CCM score of 4.2, compared to the 4Q10 average worldwide CCM of 8.7).
- The most common category in Canada in 4Q10 was Adware, which affected 35.6 percent of all cleaned computers, down from 41.0 percent in 3Q10.
- The second most common category in Canada in 4Q10 was Misc. Trojans, which affected 35.3 percent of all cleaned computers, up from 29.0 percent in 3Q10.
- The third most common category in Canada in 4Q10 was Misc. Potentially Unwanted Software, which affected 26.3 percent of all cleaned computers, down from 26.1 percent in 3Q10.
Earlier this morning I got an email from John
Bristowe congratulating me on being selected to present a session for the local
flavours track at TechDays in Toronto!
This bumps
up my count to 2. Needless to say I am REALLY excited.
I was a little disappointed to find out there weren’t any sessions on the Windows
Identity Foundation, so that just meant I had to submit my own to the local flavours
track…and they accepted it! Here are the details:
October 27, 3:40 PM to 4:45 PM
Breakout | LFT330: Windows Identity Foundation Simplified: All the Scary Things
Made Un-Scary
The Windows Identity Foundation helps simplify user access for developers by externalizing
user access from applications via claims and reducing development effort with pre-built
security logic and integrated .NET tools. This presentation is an intimate discussion
on the basics of the Windows Identity Foundation and its claims model. In this session,
you’ll learn how to refactor an existing sample set of applications to use WIF, to
connect identities to the Cloud, and to remove the burden of managing multiple disparate
user stores.
Location: Metro Toronto Convention
Centre - South Building (255 Front Street West, Toronto)
Room: TBA
When SharePoint 2010 was developed, Microsoft took extra care to include support for
a claims-based identity model. There are quite a few benefits to doing it this
way, one of which is that it simplifies managing identities across organizational
structures. So lets take a look at adding a Secure Token Service as an Authentication
Provider to SharePoint 2010.
First, Some Prerequisites
-
You have to use PowerShell for most of this. You wouldn’t/shouldn’t be adding
too many Providers to SharePoint all that often so there isn’t a GUI for this.
-
The claims that SharePoint will know about must be known during setup. This
isn’t that big a deal, but…
Telling SharePoint about the STS
Once you’ve collected all the information you need, open up PowerShell as an Administrator
and add the SharePoint snap-in on the server.
Add-PSSnapin Microsoft.SharePoint.PowerShell
Next we need to create the certificate and claim mapping objects:
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("d:\path\to\adfsCert.cer")
$claim1 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"
-IncomingClaimTypeDisplayName "Role" –SameAsIncoming
$claim2 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
-IncomingClaimTypeDisplayName "EmailAddress" –SameAsIncoming
There should be three lines. They will be word-wrapped.
The certificate is pretty straightforward. It is the public key of the STS.
The claims are also pretty straightforward. There are two claims: the roles
of the identity, and the email address of the identity. You can add as many
as the STS will support.
Next is to define the realm of the Relying Party; i.e. the SharePoint server.
$realm = "urn:" + $env:ComputerName + ":adfs"
By using a URN value you can mitigate future changes to addresses. This becomes
especially useful in an intranet/extranet scenario.
Then we define the sign-in URL for the STS. In this case, we are using ADFS:
$signinurl = https://[myAdfsServer.fullyqualified.domainname]/adfs/ls/
Mind the SSL.
And finally we put it all together:
New-SPTrustedIdentityTokenIssuer -Name "MyDomainADFS2" -Description "ADFS
2 Federated Server for MyDomain" -Realm $realm -ImportTrustCertificate $cert
-ClaimsMappings $claim1,$claim2 -SignInUrl $signinurl -IdentifierClaim $claim2.InputClaimType
This should be a single line, word wrapped. If you wanted to you could just
call New-SPTrustedIdentityTokenIssuer and then fill in the values one at
a time. This might be useful for debugging.
At this point SharePoint now knows about the STS but none of the sites are set up
to use it.
Authenticating SharePoint sites using the STS
For a good measure restart SharePoint/IIS. Go into SharePoint Administration
and create a new website and select Claims Based Authentication at the top:
Fill out the rest of the details and then when you get to Claims Authentication
Types select Trusted Identity Provider and then select your STS.
In this case it is my ADFS Server:
Save the site and you are done. Try navigating to the site and it should redirect
you to your STS. You can then manage users as you would normally with Active
Directory accounts.
A few posts back I started talking about what it would take to create a new application
for the new Windows Phone 7. I’m not a fan of learning from trivial applications
that don’t touch on the same technologies that I would be using in the real world,
so I thought I would build a real application that someone can use.
Since this application uses a well known dataset I kind of get lucky because I already
have my database schema, which is in a reasonably well designed way. My first
step is to get it to the Phone, so I will use WCF Data Services and an Entity Model.
I created the model and just imported the necessary tables. I called this model
RaceInfoModel.edmx. The entities name is RaceInfoEntities This is ridiculously
simple to do.
The following step is to expose the model to the outside world through an XML format
in a Data Service. I created a WCF Data Service and made a few config changes:
using System.Data.Services;
using System.Data.Services.Common;
using System;
namespace RaceInfoDataService
{
public class RaceInfo : DataService
{ public static void InitializeService(DataServiceConfiguration config) { if (config
== null) throw new ArgumentNullException("config"); config.UseVerboseErrors
= true; config.SetEntitySetAccessRule("*", EntitySetRights.AllRead); //config.SetEntitySetPageSize("*",
25); config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V2;
} } }
This too is reasonably simple. Since it’s a web service, I can hit it from a
web browser and I get a list of available datasets:
This isn’t a complete list of available items, just a subset.
At this point I can package everything up and stick it on a web server. It could
technically be ready for production if you were satisfied with not having any Access
Control’s on reading the data. In this case, lets say for arguments sake that
I was able to convince the powers that be that everyone should be able to access it.
There isn’t anything confidential in the data, and we provide the data in other services
anyway, so all is well. Actually, that’s kind of how I would prefer it anyway. Give
me Data or Give me Death!
Now we create the Phone project. You need to install the latest build of the
dev tools, and you can get that here http://developer.windowsphone.com/windows-phone-7/.
Install it. Then create the project. You should see:
The next step is to make the Phone application actually able to use the data.
Here it gets tricky. Or really, here it gets stupid. (It better he fixed
by RTM or else *shakes fist*)
For some reason, the Visual Studio 2010 Phone 7 project type doesn’t allow you to
automatically import services. You have to generate the service class manually.
It’s not that big a deal since my service won’t be changing all that much, but nevertheless
it’s still a pain to regenerate it manually every time a change comes down the pipeline.
To generate the necessary class run this at a command prompt:
cd C:\Windows\Microsoft.NET\Framework\v4.0.30319
DataSvcutil.exe
/uri:http://localhost:60141/RaceInfo.svc/
/DataServiceCollection
/Version:2.0
/out:"PATH.TO.PROJECT\RaceInfoService.cs"
(Formatted to fit my site layout)
Include that file in the project and compile.
UPDATE: My bad, I had already installed the reference, so this won’t
compile for most people. The Windows Phone 7 runtime doesn’t have the System.Data
namespace available that we need. Therefore we need to install them… They
are still in development, so here is the CTP build http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=b251b247-70ca-4887-bab6-dccdec192f8d.
You should now have a compile-able project with service references that looks something
like:
We have just connected our phone application to our database! All told, it took
me 10 minutes to do this. Next up we start playing with the data.
Over the past few months I have seen quite a few really cool technologies released
or announced, and I believe they have a very real potential in many markets.
A lot of companies that exist outside the realm of Software Development, rarely have
the opportunity to use such technologies.
Take for instance the company I work for: Woodbine
Entertainment Group. We have a few different businesses, but as a whole
our market is Horse Racing. Our business is not software development.
We don’t always get the chance to play with or use some of the new technologies released
to the market. I thought this would be a perfect opportunity to see what it
will take to develop a new product using only new technologies.
Our core customer pretty much wants Race information. We have proof of this
by the mere fact that on our two websites, HorsePlayer
Interactive and our main site, we have dedicated applications for viewing Races.
So lets build a third race browser. Since we already have a way of viewing races
from your computer, lets build it on the new Windows Phone 7.
The Phone – The application
This seems fairly straightforward. We will essentially be building a Silverlight
application. Let’s take a look at what we need to do (in no particular order):
-
Design the interface – Microsoft has loads of guidance on following with the Metro
design. In future posts I will talk about possible designs.
-
Build the interface – XAML and C#. Gotta love it.
-
Build the Business Logic that drives the views – I would prefer to stay away from
this, suffice to say I’m not entirely sure how proprietary this information is
-
Build the Data Layer – Ah, the fun part. How do you get the data from our internal
servers onto the phone? Easy, OData!
The Data
We have a massive database of all the Races on all the tracks that you can wager on
through our systems. The data updates every few seconds relative to changes
from the tracks for things like cancellations or runner odds. How do we push
this data to the outside world for the phone to consume? We create a WCF Data
Service:
-
Create an Entities Model of the Database
-
Create Data Service
-
Add Entity reference to Data Service (See code below)
public class RaceBrowserData : DataService
{ public static void InitializeService(DataServiceConfiguration config) { if (config
== null) throw new ArgumentNullException("config"); config.UseVerboseErrors
= true; config.SetEntitySetAccessRule("*", EntitySetRights.AllRead); //config.SetEntitySetPageSize("*",
25); config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V2;
} }
That’s actually all there is to it for the data.
The Authentication
The what? Chances are the business will want to limit application access to
only those who have accounts with us. Especially so if we did something like
add in the ability to place a wager on that race. There are lots of ways to
lock this down, but the simplest approach in this instance is to use a Secure Token
Service. I say this because we already have a user store and STS, and duplication
of effort is wasted effort. We create a STS Relying Party (The application that
connects to the STS):
-
Go to STS and get Federation Metadata. It’s an XML document that tells relying
parties what you can do with it. In this case, we want to authenticate and get
available Roles. This is referred to as a Claim. The role returned is
a claim as defined by the STS. Somewhat inaccurately, we would do this:
-
App: Hello! I want these Claims for this user: “User Roles”. I am now going
to redirect to you.
-
STS: I see you want these claims, very well. Give me your username and password.
-
STS: Okay, the user passed. Here are the claims requested. I am going
to POST them back to you.
-
App: Okay, back to our own processes.
-
Once we have the Metadata, we add the STS as a reference to the Application, and call
a web service to pass the credentials.
-
If the credentials are accepted, we get returned the claims we want, which in this
case would be available roles.
-
If the user has the role to view races, we go into the Race view. (All users
would have this role, but adding Roles is a good thing if we needed to distinguish
between wagering and non-wagering accounts)
One thing I didn’t mention is how we lock down the Data Service. That’s a bit
more tricky, and more suited for another post on the actual Data Layer itself.
So far we have laid the ground work for the development of a Race Browser application
for the Windows Phone 7 using the Entity Framework and WCF Data Services, as well
as discussed the use of the Windows Identity Foundation for authentication against
an STS.
With any luck (and permission), more to follow.
I’ve been looking at ways of parsing types and values from text without having to
do switch/case statements or explicit casting. So far, based on my understanding
of statically typed languages, is that this is impossible with a statically typed
language.
<Question> Is this really true?</Question>
Given my current knowledge, my way of bypassing this is to use the new dynamic type
in .NET 4. It allows me to implicitly assign an object without having to cast
it. It works by bypassing the type checking at compile time.
Here’s a fairly straightforward example:
static void Main(string[] args)
{
Type boolType = Type.GetType("System.Boolean");
Console.WriteLine(!parse("true", boolType));
Type dateTimeType = Type.GetType("System.DateTime");
DateTime date = parse("7/7/2010", dateTimeType);
Console.WriteLine(date.AddDays(1));
Console.ReadLine();
}
static dynamic parse(string value, Type t)
{
return Convert.ChangeType(value, t);
}
Now, if I were to do something crazy and call
DateTime someDate = parse(“1234”, Type.GetType(“System.Int32”));
a RuntimeBinderException would be thrown because you cannot implicitly convert between
an int and a DateTime.
It certainly makes things a little easier.