Silverlight 3 for the Enterprise – Part 1
I will be covering architectural patterns and design for an enterprise level Silverlight 3 application. Silverlight here is really a misnomer since the UI does not truly identify an enterprise level application, but rather the tiers and application components that make up an extensible, flexible and scalable group of systems.
The Setting
First, a little background; As a call center automation, integration and systems architect I am constantly faced with issues on integrating client systems, customer data as well as call systems, VoIP appliances, desktop environments, external resources, web services, etc. The demands of a call center application either for the web or desktop are extreme, high-volume environments where downtime = money lost and problems can perpetuate themselves quickly. This is also a very fast-changing environment where business processes, rules, semantics and strategy change rapidly and application developers and engineers are expected to keep up with an ever increasing list of demands, needs and changes from several stakeholders in short periods of time.
As a web technologies evangelist, I often lean towards these platforms to solve the implementation details of my architectural designs and concepts. Recently with the release of Silverlight 3, .NET RIA Services and a myriad of improvements to not only the control set for Silverlight but the underlying stabilization and framework changes that have been made. After the go-live license for Silverlight 3 was released July 10, I seized the opportunity to leverage this new technology for a new up-coming project with some pretty high demands for a rich, interactive UI, yet equally high demands for availability, usability as well as a large number of data and system integration points.
Step 1: Security
Taking a best practices approach, I decided to approach the issue of security first. This encompasses not only how users will log onto the application, but also how external and internal systems will communicate and authenticate themselves with our web services and the best way to secure communications between web services and the Silverlight application while respecting the new found power of client side code execution and state that Silverlight offers.
I decided the best approach was a central (quasi-central anyway) mechanism for authenticating users and requests for both internal applications, including the Silverlight application and external applications calling our external APIs.
The Problem
Unfortunately, to create a single platform for authentication and authorization is tough when you throw a technology like Silverlight into the mix which doesn’t have support for ws-* security standards, client/server certificates, packet signing, etc. We needed a simple web service to act as a Security Token Service using basic HTTP messages over HTTPS/SSL. Then we need to create sessions and encrypted payloads for a “token” or key that could be passed over a period of time with any messages to a trusted service in order to authorize the web service call and/or authenticate the user. We also need to provide a means for respecting “minimum data transfer and server calls” between services, so a way to pass authentication credentials with each request as an alternative to going directly to the STS service to obtain a signed credential.
The Solution
The solution presented itself with a concept of a central (or pooled) service that would act similar to an STS Service, but no behave entirely like the STS token providers in WCF. Essentially the service takes in authentication credentials, authenticates the user and returns an encrypted token and validation hash containing easily discoverable plain text XML attributes for expiration date/time as well as session id. Inside the encrypted payload we would include other details such as the user name and machine name/IP Address of the requestor. Each web service, or the Silverlight application, would then pass this credential in the header of any SOAP call made to any of the other web services, which would in turn validate the request and check the requestor’s roles, access and authorization against the STS Service’s trusted service method calls. Trusted calls would then be made against WCF bindings requiring trusted certificates across internal web and services servers.
Internal services also cache their applicable connection strings and configuration settings from this service when starting or fulfilling a request so based on the account they know which customer database to access. These are also trusted service calls that cannot be made externally without the proper certificates and bindings.
The final outcome of the STS Service design looks something like this (rough draft):
STS Service Architecture
Next week I will try to post the next portion of this enterprise Silverlight architecture, the service bus and state manager.
