Identity management is a complex problem yet almost every application has to address it.
The world of identity management is going through a revolutions with the introduction of WS* standards. Federation, Single sign on and claim based authorization are common requirements. The question that remains open is: How should it be implemented?
Every framework has to address the identity problem. In this column I would like to introduce the .Net solution called "Windows Identity Foundation" previously known as Geneva framework.
Windows Identity Foundation (WIF) enables the .NET developers to externalize identity logic from their application, improving developer productivity, enhancing application security, and enabling interoperability. Windows Identity Foundation (WIF) can be used for on-premises software as well as cloud services. Windows Identity Foundation (WIF), which is part of the new Identity and Access products wave, gives applications a much richer and flexible way to deal with identities by introducing claims-based identity concept.
Using WIF it is easy to implement a claim based authorization systems based on industry standard protocols. WIF simplifies the creation of a security token service - STS (which is the center of every claim based system) as well as the interaction with other existing STS and resources.
Windows Identity and Access platform includes several releases.
· Active Directory Federation Services 2.0
· Windows Identity Foundation
· Windows Cardspace 2.0
ADFS 2.0
ADFS 2.0 is the next generation of Active Directory Federation Services.
At the core of ADFS 2.0 is a security token service (STS) that uses Active Directory as its identity store. The STS in ADFS 2.0 can issue security tokens to the caller using various protocols, including WS-Trust, WS-Federation and Security Assertion Markup Language (SAML) 2.0. To support old versions ADFS 2.0 STS supports both SAML 1.1 and SAML 2.0 token formats.
AD FS 2.0 is designed with a clean separation between wire protocols and the internal token issuance mechanism. Different wire protocols are transformed into a standardized object model at the entrance of the system while internally AD FS 2.0 uses the same object model for every protocol. This separation enables AD FS 2.0 to offer a clean extensibility model, independent of the intricacies of different wire protocols.
Windows Identity Foundation - System.IdentityModel
WIF is a framework for implementing claims-based identity in your applications. It can be used in any Web application or Web service, cloud or on premise applications.
The goal was to make the interaction with claims easy. It is designed to unify and simplify claims-based applications. It builds on top of WCF’s plumbing to implement WS-Trust and comes with an HttpModule called the WS-Federation Authentication Module (FAM) that make it trivial to implement WS-Federation in a browser-based application.
Using WIF it is possible to create your custom STS or connect to another identity provider with only few lines of code.
For example when you build a relying party with WIF, you’re shielded from all of the cryptographic heavy lifting. WIF decrypts the security token passed from the client, validates its signature, validates any proof keys, shreds the token into a set of claims, and presents them to you via an easy-to-consume object model.
Cardspace 2.0
Cardspace is an identity selector. To a user a Cardspace represent his identity in a simple and friendly manner. Cardspace is very much like the ID card in your wallet or a personal card you distribute to your colleagues. The card is installed on the user computer. The information contained in the card is not the user identity. The card contains the information needed to fetch the identity info from the identity provider.
Cardspace is not a new technology. It was released with .Net framework 3.0 back in 2005. Cardspace was not a huge success because it was not easy to use. WIF will change that.
WIF introduce all the plumbing needed to use Cardspace on the client and the infrastructure to build or use an identity provider on the server. In Cardspace 2.0 there are many performance improvements to assure its use will be easy and comfortable.
The identity problem is complex, the challenge is huge but on the other hand it must be easy to create applications with advanced identity capabilities.
WIF together with the Microsoft’s Identity and Access Platform allows exactly that.
Security and identity are a global issue and thus interoperability between all platforms is a necessity. Microsoft’s Identity and Access Platform is based upon well known industry standard protocols to make sure it will fully comply with the interoperability requirement.
The world of identity is going through a revolution with claim based authorization systems. If you want to be up to date I recommend to take a close look at WIF and Microsoft’s Identity and Access Platform.
So much had changed between Beta 1 and Beta 2.
You are all wandering where can we find the new samples/
Here is the link: wcf_wf_samples.
Matt Winkler has a blog post here that outlines changes between Beta 1 and Beta 2:
Here is the link to the Breaking Changes document:
http://go.microsoft.com/fwlink/?LinkId=169193
Lat but not least the link to the Endpoint Code Migration post:
manu
I have just returned from the IDC 2009 convention which was dedicated to cloud computing.
A nice definition for cloud computing was: Infrastructure as a Sercice. (IaaS).
Actually cloud computing is just "A new way to do IT".
Cloud computing can be divided into 3 major subjects:
1. IaaS – Infrastructure as a service – Provisioning a virtual machine from the cloud. (Example: Amazon web services)
2. PaaS – Platform as a Service – Provisioning a platform on which you can develop and host applications on the cloud (Example: Windows Azure)
3. SaaS – Software as a Service – Provisioning a solution on the cloud instead of an on premise software (Example Live Dynamics)
Another interesting subject was the definition of private cloud vs. public cloud.
Private cloud takes virtualization one step further and makes it dynamic and more efficient. Yet it happens within the firewall inside the enterprise.
Public cloud happens within the major players (Microsoft, IBM, Google, Amazon etc) Data centers.
There are many private cloud solutions which are already in use today. We will have to wait some time until we will be able to see major applications running on the public cloud, but there is no doubt it is the future.
Eliaz from Microsoft presented Windows Azure. There is no doubt it was the best talk of the day.
I am really excited about cloud computing…
WCF does not promise thread affinity. This means that WCF does not promise that the thread that started the service operation execution will be the one who will finish the execution. In case the operation waits on some wait handle (wait for IO or DB for example) the thread might return to the thread pool and when execution should resume another thread might do the work.
public class MyService : IContract
{
public static object wait_handle;
public int LongOperation()
{
Before();
LongWait(); //Threads might be switched here
After();
return 0;
}
}
This fact enhance WCF scalability might introduce interesting synchronization scenarios.
If the operation is synchronized using a monitor (Using statement) it means that a Sync_Handle is associated with the thread.
If the execution thread is switched (no thread affinity) the second thread does not have the sync handle and the code will wait. On the other hand the starting thread might be assigned to another WCF request (after it was sent back to the thread pool). This next request have the sync_handle, it would not wait and it might cause damage to synchronized resources.
public class MyService : IContract
{
public static object wait_handle;
public int LongOperation()
{
lock (wait_handle)
{
Before(); //Thread1 has the lock
LongWait(); //Threads might be switched here
After(); // Thread2 does not have the lock but
it runs.
return 0;
}
}
public int SecondOperation()
{
// If accidently Thread1 is allocated it has the
handle and would enter the lock.
lock (wait_handle)
{
DoWork();
}
return 0;
}
}
The solution is simple.
Whene there is no thread affinity do not use monitor and the using statement. Use Events (autoReasetEvent or ManualResetEvent). When WCF perform a thread switch the second thread can set the event and the synchronization will continue as planned.
One of the problems with WF 3.5 is the debugging experience.
One of my customers complained that he could not put a break point on an activity in a workflow that was dynamically loaded to the runtime.
I checked and found out that it is simply not supported.
It is impossible to break on a workflow when it is dynamically loaded unless the breakpoint is put in the workflow code.
The problem is that usually the workflow has no code. It is made of pre created activities. Only when code activity is used or handlers are registered to events there will be code to break on.
Let us all wait to WF 4.0
There was a lot of effort to make WCF interoperable with almost every web service technology out there… But what about native code?
How can native code call a WCF service? How can native code be exposed as a web service?
Well you could always wrap native code with managed code but this introduced too many introp calls which degrades performance. You could also program against TCP sockets but manually implementing WS* is a nightmare.
Windows 7 brings an answer: wssapi – Windows Web Service API.
with wssapi you can easily create a native proxy to a WCF service. You can also expose your native code using a native service and a native host and create a web service that looks and feels like a WCF service.
To learn more about in I strongly recommend watching the following videos.
- Native Web services Part1
- Native Web services Part 2
- Web Services in native code
wssapi will also support XP Server 2003 and Server 2008.
Enjoy
Windows Server "Dublin" is a collection of enhanced capabilities added to the Windows server platform which will expand and take Internet Information Services (IIS) to the next level. The end purpose of the improvements planned for the Windows Application Server is to permit developers to handle composite applications in a much simpler way than they can today.
Dublin will allow simple Yet powerful WF and WCF hosting.
Dublin includes a set of advanced logging and monitoring capabilities that will enable easy management of large sets of services and WF instances. A First look an Dublin can be found here.
The question is when?
So here is the timeframe that was released with the Dublin Technology Adoption Program (TAP).
Q3 2009 (Oct-Dec)
Beta 1 release
Q1 2010 (Jan-Mar)
Beta 2 release
Q2 2010 (Apr-Jun)
RTM
One of the most frequent feedbacks the .Net services got about WF in the .Net services was why do you use WF 3.5 and not WF 4.0?
So they won't.
The .Net services will use WF 4.0 but they cannot do that until WF ships (22 March 2010) so until then WF was simply removed. Here is the formal announcement.
Let us wait.
There is no doubt that this was the right thing to do.
It is time for the big customers to move to WCF.
WCF is 5 years in the market. We are moving into the third version (WCF 4.0) and there is no doubt that WCF is mature enough for the big customers (who hate to take risks).
The managers ask me: Why WCF ? So I wrote this short summary for executives to read:
WCF is a unified framework for rapidly building service oriented applications.WCF is the most powerful of all distributed applications frameworks, yet it is the simplest to work with. WCF introduce the following advantages:
· Simple programming model
o Low learning curve
o Short development time.
o Similar object model for all communication technologies.
o Simple debugging and maintenance
· WCF support WS* standards
o With WCF it is possible to enjoy the capabilities introduced by WS* Standards like:
§ Security
§ Federation
§ Transactions (simple and distributed )
§ Reliable messaging
§ Routing (WS Addressing)
§ Policy (WS Policy)
§ Metadata exchange
§ Service Discovery
o Because WCF implements known standards it interoperable with other frameworks (for example all J2EE frameworks)
· Performance
o WCF has the best performance in comparison to other services connectivity frameworks.
· Extensibility
o WCF has numerous extension points where you change its behavior or make it implement your protocols and constraints.
o WCF can enable communication between SOA applications in any communication protocols including proprietary ones.
· Communication patterns
o Support for many communication patterns like:
§ Request response
§ One Way (Datagram or asynchronous calls)
§ Duplex
§ Pub-sub
§ Streaming
· Support for advanced topologies
o Content based routing
o Broker
o Service façade
o Custom
· Support for REST
o WCF is a full RESTful framework
o It is possible to create syndication Feeds in several formats.
o Intimate HTTP and URI support.
· Known and leading technology
o WCF Microsoft's leading service oriented technology thus all SOA integration and maintenance tools today support WCF.
o Microsoft SOA technologies are based on WCF.
· Maintenance and governance
o Powerful configuration.
o Built in tracing including ETW support.
o Built in performance counters
o WAS on IIS7.0 and Dublin (released in the near future) are hosts for WCF services with built in advanced governance capabilities.
· Tools
o Full Visual studio support
o Tracing and configuration tools.
o Many community and commercials tools
Hope this will help.
There are very important changes between the two beta versions as was just published by the WF and WCF team blog.
I would like to summarize the most critical updates. (There more changes I will describe in future posts)
1. The activity class hierarchy changed dramatically.
From :
To:
- WorkflowElement goes away, and is replaced with Activity. Activity is the root type for all units of execution within the world of WF
- Addition of ActivityWithResult which is the base for the Expression activities
- Addition of AsyncCodeActivity. We got a lot of feedback that people liked what we were doing integrating asynchronous programming within activities but that there was still a fair amount of work in order to hook those up. AsyncCodeActivity is some nice sugar that makes it pretty easy to write an activity that takes advantage APIs that surface a Begin/End pair using the asynchronous programming model.
2. WorkflowInstance was renamed to WorkflowApplication
3. Correlation
- XPath can now be generated from ParametersContent
- CorrelationQuery and AdditionalCorrelations have been merged into a collection called CorrelationInitializers. Also, we’ve reduced the need for CorrelationHandles all over the place by improving the CorrelationScope and having an implicit correlation handle.
4. Parameters support : The Parameters activities were removed and merged into the Send and Receive activities. You can now use the Content property to support MessageContent (primarily for untyped Message or MessageContract ) and ParametersContent (which is for the more RPC style list of name value pairs).
Enjoy.
Live services as you all knows allows you to access share and synchronize your data.
Once you add your devices to the mesh you can synchronize your data and application between your devices. share your data with your friends and family and access the data from anywhere using the live desktop.
This is remarkable. To enable that there must be a shared data model between all your devices and the cloud.
In this post I want to describe the Live services resource model.
The following famous diagram describes the model:
Let us explain.
The Live Framework Resource Model describes various resources and their relationships to other resources. It is based on a simple Property, Entity, Collection based information model. Each resource is an entity which contains various properties and a set of entities make up a collection. Every collection and entity is uniquely addressable and is identified by a URL. The relationships between entries are represented through hyperlinks. This allows for navigation from one resource to the related resource (entity) or collection of resources (collection). Note that such an entity/collection based model can be transformed trivially to an item/feed based information model of RSS or ATOM.
At the heart of the resource model is Data Entry. Data Entry is the representation of a single unit of data such as photo, a document, a blog post etc. Each data entry contains textual information which describes the data and the link to the binary information - the media (video, photo, etc).
Media related to the data entry is linked via the “EditMediaLink” property and is stored under Media Resources.
A Data Feed is a collection of data entries. In most cases a data feed will be a logical collection of similar / related data entries, however, the content and type of data entries present as part of a data feed is whatever you want it to be.
A collection of data feeds can be represented by a container which we call as a Mesh Object. Usually data feeds grouped under a Mesh Object will be logically related but there is no such binding.
Mesh objects are the basic unit of extensibility, data synchronization and sharing in the Live Framework Resource Model.
All of a user’s data is represented by a collection of such mesh objects and they can be referenced via the user’s Mesh.
Each mesh object not only exposes the collection of data feeds which contains user data (MeshObjects) but also some other important collections :
1.Mapping:
Every mesh object can be synchronized to multiple devices in a user’s mesh. Information on devices on which a given mesh object is synchronized is available via the mappings feed where each entry provides information on a single device where this mesh object is present.
2.Members:
Every mesh object can be shared with multiple people in various capacities.
Every entry in the members feed provide information on every user who has access to the given mesh object
and the type of access they have.
3.News:
Whenever a data entry is added, updated or deleted under a given mesh object, the system automatically generates news events.
These are also generated whenever there is an addition / deletion to the members feed or mappings feed for the mesh object.
Each such news event forms an entry in the news feed for the given mesh object.
4.Subscriptions:
Users can subscribe to changes to mesh objects such that they can be notified and can potentially take appropriate actions.
Other important resources exposed via Mesh in addition to Mesh Objects are
1.Devices:
Information on all the devices on which all or some of the mesh objects are synchronized is available via the devices feed where each entry in the feed provides information on a single device.
2.Applications:
Collective information on all the Mesh enabled applications deployed on the mesh for that particular user.
3.News:
Collective information on all the news entries for all the mesh objects and global news related to the user is available via the news feed where every entry represents a single news event.
4.Notification Queues:
A collection of queues that receives notifications about changes to a certain resources. When registering for notification to a particular resource a notification queue is created. It is possible to create a queue for notifications about multiple resources.
I was looking for a tool to read ETW tracing data. It turned out that the tool I need is right under my nose. Event Viewer.
The problem was that ETW (using the logman tool) produces etl files that are not readable by Event Viewer. Fortunately there is a trick. I tried to load the etl file by Event Viewer using open saved log and it failed to load.
Event Viewer
I saved the etl file as an evtx file and now I could see the tracing data.
For WCF and WF you do not need the etl file. All you have to do is follow the following procedure:
Enable the analytic and debug logs.
-
In the tree view in Event Viewer, navigate to Event Viewer->Applications and Services Logs->Microsoft. Right-click on Microsoft and select View->Show Analytic and Debug Logs.
Ensure that the Show Analytic and Debug Logs option is checked.
Enable the Analytic log.
In the tree view in Event Viewer, navigate to Event Viewer->Applications and Services Logs->Microsoft->WCF->WF-Development. Right-click on Analytic and select Enable Log.
Activate a WCF service with tracing enabled and all the tracing data will be there.
It basically solves the challenge of generating a "unique" address for an endpoint when you don't know what's already in use. Here's how it works:
<system.serviceModel> <services> <service name="WcfTests.MathService"> <endpoint listenUriMode="Unique" address="net.tcp://localhost/math" binding="netTcpBinding" contract="WcfTests.MathService"/> </service> </services> </system.serviceModel> |
Using this configuration with TCP endpoints causes WCF to automatically choose a "free" port number -- it also appends a unique GUID to the end of the address to ensure uniqueness. For HTTP and named pipes it only appends the GUID to the address, it doesn't generate a unique port number.
When I run this configuration, the listener address for this endpoint is:
net.tcp://localhost:39619/math/908ae8dc-7427-407a-9ea4-8aeecdfa62be
When the value of the ListenUriMode is set to Unique the transport is responsible for creating a unique URI. Different transports used by Windows Communication Foundation (WCF) generate this unique URI differently:
- For TCP in exclusive mode (PortSharingEnabled is false) this means binding to a uniquely available port number.
- For TCP in port sharing mode (PortSharingEnabled is true) and for all of the other existing WCF transports, this means appending a unique path (a GUID) to the end of the ListenUri.
When using ListenUri.Unique the discovery capabilities of WCF 4.0 are a perfect match.
On the server side the ListenURI will be set automatically to be unique and the client will find about the chosen ListenURI using WS discovery.
After the client had learned about the unique URI from the discovery information
(var viaUri = discoveredEndpoint.ListenUris[0]) all it has to do is to point the proxy to the right spot using : clientProxy.Endpoint.Behaviors.Add(new ClientViaBehavior(viaUri)
Simple and clean.
In WCF 3.x, type resolution was done using the “known types” mechanism. During deserialization, when the serializer encounters an instance that isn’t of the same type as the declared type, it inspects the list of declared “known types” to figure out what type to use.
As the author of the service, you could annotate your types/methods with the [KnownType] or [ServiceKnownType] attributes to define the list of possible substitutions. (in code or config)
Unfortunately, WCF 3.x doesn’t provide an easy way to override the type-mapping algorithm used by DataContractSerializer when performing this type of dynamic type resolution at runtime. This means that it was not possible to implement true polymorphism. It was not easy to make sure the serializer will serialize the correct type in the inheritance tree.
The result was flat data contracts.
Personally I think that flat data contracts are good. It makes services simpler and interoperable but I am not happy that a polymorphic data contract is not possible or very difficult to implement.
I think that the service should be just a facade to the business logic. The actual business entities should not exposed. The data contracts are just flat containers from which the business entities are created.
There are scenarios where the actual business entities should be exposed. In those scenarios we would like to serialize a polymorphic hierarchy of data contracts.
In WCF it is possible and easy using the DataContractResolver.
WCF in .NET 4 provides the abstract DataContractResolver class that you can derive from to implement your own custom type resolution algorithm. Your resolver implementation is provided to the DataContractSerializer instance :
var serializer = new DataContractSerializer(typeof(Object), null, int.MaxValue, false, true, null, new MyDataContractResolver());
The new serializer can be bound to the WCF infra using a custom behavior and you are done.
The new WCF_WF SDK samples has a simple example how to implement such resolver.
In WF and WCF 4.0 there are new logging (tracking) mechanisms that uses the ETW.
What is ETW?
Event Tracing for Windows (ETW) is a general-purpose, high-speed tracing facility provided by the operating system. Using a buffering and logging mechanism implemented in the kernel, ETW provides a tracing mechanism for events raised by both user-mode applications and kernel-mode device drivers. Additionally, ETW gives you the ability to enable and disable logging dynamically, making it easy to perform detailed tracing in production environments without requiring reboots or application restarts. The logging mechanism uses per-processor buffers that are written to disk by an asynchronous writer thread. This allows large-scale server applications to write events with minimum disturbance.
ETW was first introduced on Windows 2000. Since then, various core OS and server components have adopted ETW to instrument their activities, and it's now one of the key instrumentation technologies on Windows platforms. A growing number of third-party applications are using ETW for instrumentation as well, and some take advantage of the events provided by Windows itself. ETW has also been abstracted into the Windows preprocessor (WPP) software tracing technology, which provides a set of easy-to-use macros for tracing "printf" style messages for debugging during development.
On Windows Vista, ETW has gone through a major upgrade, and one of the most significant changes is the introduction of the unified event provider model and APIs. In short, the new unified APIs combine logging traces and writing to the Event Viewer into one consistent, easy-to-use mechanism for event providers. At the same time, several new features have been added to improve developer and end user experience.
ETW architecture can be described like so:
There are four main types of components in ETW: event providers, controllers, consumers, and event trace sessions. Buffering and logging take place in event tracing sessions, which accept events and create a trace file. There are a number of logging modes available for ETW sessions. For instance, a session can be configured to deliver events directly to consumer applications or to overwrite old events in a file by wrapping around when a certain size is reached. A separate writer thread created for each session flushes them to a file or to real-time consumer applications. To enable high-performance, per-processor buffers are used to eliminate the need for a lock in the logging path.
An event provider is a logical entity that writes events to ETW sessions. Any recordable activity of significance can be an event, and each is represented by an event logged to ETW. An event provider can be a user-mode application, a managed application, a driver, or any other software entity. The only requirement is that the event provider must register a provider ID with ETW through the registration API. A provider first registers with ETW and writes events from various points in the code by invoking the ETW logging API. When a provider is enabled dynamically by the ETW controller application, calls to the logging API send events to a specific trace session designated by the controller. Each event sent by the event provider to the trace session consists of a fixed header that includes event metadata and additional variable user-context data. Due to the growing event instrumentation in many OS components, even a simple application for Windows Vista will already contain several components that are event providers.
When an event is logged to a session, ETW adds a few extra data items along with the user-provided data. They include timestamp, process and thread ID, processor number, and CPU usage data of the logging thread. These data items are recorded in the ETW event header and passed on to event consumers along with the variable event content given by the provider. Many trace consumers find these data fields to be essential in their analysis.
A controller starts and stops ETW sessions and enables providers to them. In some scenarios, such as debugging and diagnosis, a controller tool is invoked as needed to collect in-depth traces.A controller must have ETW permission on Windows Vista to control sessions, which is given only to a small group of privileged users by default.
a consumer is an application that reads log files or listens to a session for real time events and processes them. Event consumption is callback-based; a consumer registers an event callback, which ETW calls with one event at a time. Events are delivered to the ETW consumer in chronological order. There are general-purpose event consumer tools that dump the events into various formats.
On my next post I will show how to use ETW in WF and WCF 4.0
More Posts
Next page »