Note: This is part of a series, you can find the related posts here…

The last post used the new Application Extension Services (AES for short) to include security into the application. This time I’m going to take AES one step further, laying out yet another piece of basic infrastructure.

As a quick recap: An AES is a simple class, implementing a simple interface (IApplicationService) and optionally another one (IApplicationLifetimeAware). It is then registered by the developer via the app.xaml. SL3 instantiates the AES at runtime and calls the respective callback methods on said interfaces, including StartService, StopService, and others. The recommended way to use these services is to maintain a static property and reference the class accordingly.

Basically AES solve one problem: How do I extend the global application class, without actually replacing it, i.e. without providing a derived class?

The problem here is that many libraries need some kind of global anchor and in the past, tool developers often chose to provide this by subclassing the next available central artifact (e.g. the page class or the application). And the next tool developer doing the same rendered those two libraries mutually exclusive, just by employing an adverse implementation strategy.

However, SL3 solves only the providing part of the equation, the part related to the application class and the instantiation of the AES. But look again at the consumer code:

Following the recommendations, I get singleton access to some object. Worse, the calling code is directly and tightly coupled to the AES class. But frankly, do I need SL3 to implement a singleton? Certainly not. Then why use AES in the first place?

What I’d love is to have the consumer code depend on some service (read interface), not on the actual implementation. And the ability to swap those services in and out, without affecting the caller. Matter of fact, the calling code doesn’t and shouldn’t care whether I use a SecurityServiceThatGetsItsInformationFromTheServer or a SecurityServiceThatGetsItsInformationFromWindowsAzure (or google account, open id, whatever).

If I could get that, AES would become a very valuable feature… . 

Introducing Service Providers

OK, what the calling code needs is some service in terms of a contract, say ISecurityService, that it can ask for. And the same is true for any crosscutting concern, such as error reporting, tracing, caching, you name it. And actually .NET has already addressed this need with the service provider pattern. This pattern has been used for example in WF (e.g. to introduce workflow instance persistence), and quite extensively in the Visual Studio design time infrastructure.

OK, I can hear you crying out DI. And the chorus chanting Unity or Ninject (to name just two that support SL). But think again. Would you (or rather a library developer) mandate a specific DI container without reason? And you can always wire your pet container into this pattern by providing a IFactory service using whatever container you like. After all, the pattern handles access to services, not instantiation of them. (Which is what AES does, but again, Microsoft chose not to provide a fully fledged DI container…)

What do I need to make this approach tick? I need a GetService method that iterates all AES – they are available via Application.ApplicationLifetimeObjects. And I need something to attach this method to. Using an extension method I can actually attach it to the application class:

The method iterates all AES, checks whether one implements the requested (interface) type. It also checks whether any AES itself follows the pattern and implements IServiceProvider, and respectively forwards the request if it does. (This allows me to build up a chain of providers.)

That’s it. Long talk, short implementation, all set

Reimplementing the SecurityService

Now I need the rework the SecurityService and the calling code to comply with the pattern. The service interface is simple enough:

And my revised security service looks like this:

The base class ApplicationServiceBase implements the two interfaces with respective empty virtual methods, thus I only had to overwrite StartService. Aside from some reformatting the most notable difference with the previous implementation is the absence of the static Current property to access the service instance at runtime. I also renamed the class to reflect what it does. Since the calling code won’t refer to that name any more, this is now feasible.

Accessing the service at runtime is done – drum roll please – using the service provider pattern. This (admittedly not exactly nice) code can be hidden in a simple static property, adding a little convenience. I did this with a class that provides a static property, but also allows calling an extension method on the Application class:

BTW: Wouldn’t it be nice to have extension properties that I could attach to the application class…?

And the calling code, i.e. the access to the user object changes to:

Now the calling code is completely decoupled from the actual implementation of the security service, meaning I could replace it without affecting the calling code.

A look ahead: Building on the pattern

There are several use cases for this pattern that I will employ (they may or may not be addressed in later posts, but at least this list should give you some ideas):

• Last chance exception handling: A service will react to the unhandled exception event and gather context information. It will then use another service to report the error.
• Message boxes: I will need message boxes for errors, information, and confirmation. The system MessageBox is however somewhat dull. A service will cover that and a later implementation will replace the boring system dialogs with nice and shiny replacements.
• Logging and tracing: At some point I will have to tackle these demands.
• …

I’m sure you can think of other examples, like navigation with parameter passing, global state, caching, …. Anyway, I think this is motivation enough to roll out some additional infrastructure.

As a side note: Actually I had a completely homegrown implementation of this pattern for SL2. When SL3 came out and offered AES I quickly jumped on the bandwagon and threw away most of that code. If only Microsoft had not stopped one step short of my needs… . I’d rather have the platform support that out-of-the-box. And given the simplicity of the remaining implementation this shouldn’t have been too much of an issue.

That’s all for now folks,
AJ.NET

OK, back down from vacation – proud about the accomplishment and perhaps with some new perspectives. It really makes you think about the effects of the financial crisis if you happen to work primarily for banks… . Well.

Note: This is part of a series, you can find the related posts here…

The last post (pre-Kili ) provided me with the necessary infrastructure to address the next topic: application security.

Silverlight is “secure by design”. It runs in a sandbox, only allowing restricted access to the local machine. Regarding server calls it supports HTTPS and windows authentication for intranets, it restricts URL access and allows only calls to servers explicitly opted in for. From a .NET perspective it has a changed programming model, no longer supporting CAS, but a more simple model that takes the restrictions into account that are already in place. It has the well-known interfaces IPrincipal and IIdentity in place, yet no implementation and no anchor to ask for them, like HttpContext.User in web applications.

Silverlight is so secure, it doesn’t even tell you, who you are.

From a purely technical perspective this is perfectly in order. The services I call are running on the server and it’s their job to make sure no one does something or gets to know something he isn’t entitled to.
On the other hand, many intranet applications need to know the user name, if only to display it. And they need the permissions granted to the user to hide buttons, menu entries or make edit fields read only – none of that for actual security reasons (the server would take care that the user couldn’t do any harm, anyway), but to improve the user experience, not letting him do things and telling him afterwards that he has had no permission to do what he did in the first place.

User and roles are available at the server at the ASP.NET runtime, and one “only” needs to make it available to the client. Matter of fact, ASP.NET provides the necessary service implementation readily available. This is also the way to integrate with ASP.NET forms authentication.

There are two caveats with this approach, though: These ASP.NET services provide roles and all, but they just don’t include the user name. Also, being services, I would have to call them asynchronously, which would incur at least a little time lag after starting the application, that I would have to deal with. A time lag that is unnecessary in intranet applications where the user is determined by windows authentication.

Thus my solution is as follows:

1. On the server include the information about user name and his roles in the initparams, so that it is available for the SL application right form the start, without any lag.
2. On the client pick up that information and mimic HttpContext.User to have a similar developer experience.

Of course, someone could fake this data, which might at first glance be a security flaw. But as I said, this information is only used to improve the user experience. Even if someone masqueraded as a different user, the sandbox on the client side still uses the actual user’s restrictions. And the same is true for the services that still have the responsibility to enforcing security anyway. I’m also not revealing sensitive information, since user name and permissions are not exactly protected data. And finally I could load the web page containing this data via HTTPS. Thus, form a security perspective I’m on the save side.

Server side

The server side is easy enough, since the necessary work has already been done. Step one is to include the information in the initparams within the ASP.NET page:

Step to is the respective implementation:

Client side

Mimic HttpContext.User? Well, there is no HttpContext, but we have the Application object which can be seen as a pendant of sorts. (I wouldn’t relate it to the HttpApplication, though, since an application in the ASP.NET sense spans all users.) Yet I’m reluctant to provide a base class to inject my pet feature, because that would bring me into conflict with any other library that may one day choose to do the same.

Luckily SL3 introduced the new concept of Application Extension Services (AES for short). AES have to implement a simple interface and are registered via the app.xaml. SL3 instantiates them and calls the StartService and StopService method to provide the hooks for initialization and shutdown. There will be another post about AES, thus I’ll leave it at that for now. Anyway, here’s the respective implementation:

It’s straight forward, it merely parses the information provided via the initparams. And the registration that will create the service at runtime is quite simple:

This is backed by boilerplate implementations of IPrincipal…

… and IIdentity:

From here I can use the user information at leisure, as I need it, and as I’m used to do. For example:

That’s all for now folks,
AJ.NET

Moved: http://alexanderj.wordpress.com/2009/10/07/das-erste-buergerrecht/

Note: This is part of a series, you can find the related posts here…

Configuration of ASP.NET applications is quite potential. Simple application settings, database connection strings, complex configuration data. All editable by the administrator after deployment.

Configuration of SL applications is virtually non-existent.

While a Silverlight application may have less need for configuration than a web application – part of the logic still remains server side in respective services anyway – it’s not as if there is no need at all.

The service URLs (or a base URL) themselves, for example. Service proxies are created with the very URL that was used to provide the meta information baked into the code. Since this is probably a local address on the developers machine it needs to be adjusted during runtime. And preferably the administrator should be able to reconfigure the SL application if the service URL changes.
Other use cases include the usual: Whatever you want to put in some appSettings replacement. Enabling debug features. Just have a look at your last web application’s configuration and you’ll probably find some good candidates.

Silverlight configuration

Looking at the object tag for a Silverlight control on a web page (the ASP.NET server side control we had with SL2 is gone with SL3), there is some technical parameterization available:

You can find a complete list of available parameters here and below.

Of particular interest right now is the initParams property. It allows me to pass arbitrary information to the SL client. It is however not suited to be maintained by an administrator, as I certainly don’t want him to mangle my web page. However nobody says I cannot provide code that reads the information from somewhere else, like so:

and the respective code, obviously intended to read in the contents of a config file:

That config file is a simple analogon to the standard ASP.NET appSettings:

Note: I could have returned the web.config appSettings section. Yet using a separate file helps keeping client and server configuration cleanly separated.

So, what’s left is the actual implementation of that InitParams class, I’ve been using…

Implementation

The InitParams class is merely a little helper, providing a fluent interface over a dictionary and convenience methods, as I needed them:

Reading the config file is equally simple with XLinq at our disposal:

And I will complement that with additional helpers in upcoming posts.

What’s it worth?

So now I have the ability to provide configuration to my client, the information readily available to be picked up during the startup event or anytime from Application.Host. For simple values I have the configuration file, for other information I can extend my helper class anytime I want (and I will!), the infrastructure is there.

Could that have been done otherwise? Well, a respective services would have been another option. But providing the information via the initparams has the advantage of being readily available to the client without delay. And configuring the configuration service via the configuration service…? Well.

That’s all for now folks,
AJ.NET

Moved: http://alexanderj.wordpress.com/2009/09/29/die-groesste-gefahr-fuer-unseren-rechtsstaat/

So, PDC09 is not far away. But, sadly, I’m not going to make it this time.

I had thought for a longer time about posting some pictures from PDC08 as kind of a retrospective – but you know how it is, other things coming up, not much time, well.

And then this nut showed up, hijacked my blog and posted this nonsense about some crime that should have happened last PDC? Come on! Here’s the list of what I can only call a real good example of real dumb accusations:

• PDC08 – the unrevealed crime (featuring Anders Hejlsberg)
• Part 2: Management Panics (featuring Ray Ozzie)
• Part 3: Early Responses (featuring Bob Muglia, Steven Sinofski, and others)
• Part 4: One Special Response (featuring Chris Anderson and Don Box)
• Part 5: The Investigation (featuring Channel 9 and the audience!)
• Part 6: A Copy Cat (featuring Scott Guthrie)
• Part 7: The Revelation (featuring Bob Muglia again)
• Part 8: The Guilty (featuring Don Box – talk about nuts)
• Part 9: Aftermath! (featuring PDC, L.A. and Halloween)

Let me stress that again: There is no proof whatsoever to this story! As I see it, all these accusations are groundless, all people addressed are innocent victims. So, please, do not accuse anyone of installing LINUX on somebody’s machine if you don’t have proof. Much less on the grounds of this story!

All that remains for me is some complementary pictures:

 Windows Azure was THE big announcement at PDC08, and it’s going to be one of the major topic for PDC09. Microsoft really has something here that might change a lot in the long run. If they remove the two road blockers, that is: One, they need to make this infrastructure available for enterprise customers to lower the barrier to entry. Two, they need to do what they always did: attract developers and create a prosperous community of enthusiasts around Azure. To achieve that, they need to offer the platform for free. All with reasonable constraints of course. And this is just my opinion.   

Oslo, and M, was another major topic. But I can’t help thinking that this was mainly because it was the “Don Box-Topic”. It’s been relatively quiet around it since then, and unfortunately this also includes the somewhat related “Dublin”, which I think is a very important step in the services area.

Hands-On-Labs was as always the best way to lay your hands on the stuff you heard about for the first time just this very morning. If you had the time.

Talking about the location, the first and the last thing you saw about PDC was L.A. …

the Convention Center…

… and if you didn’t use the shuttle system, it was probably Pico Station, featuring a great view at Downtown.

However, I have been attending 3 PDCs so far, all of them in L.A. I’d really like to see some other city next time? (Microsoft, I could give you a list of areas in the U.S., I haven’t visited so far ).

So much for my little retrospective. CU at PDCnext… .

That’s all for now folks,
AJ.NET

Hi had barely recovered from the shock when I realized that I needed proof and witnesses if anyone was supposed to believe this story, and not dismiss it as a conspiracy theory. It was a foregone failure…

I tried various channels:  

Officials didn’t know (or reveal) anything!

Other attendees searched for some kind of evidence – no success either.

  The local muscle knew nothing.

Law enforcement was as confused as I was.

When the PDC closed the doors for the last time, after sunset in L.A., I know that everything was lost.

The next day was October, 31st, and I still remember this strange girl, claiming to know something, but not really telling. Beyond some slightly insane giggle…

PS: This is it. I told it all. Obviously I will not come to this years PDC, not to watch an even more horrid crime unfold. To those still planning to go there: I wish you all a good time and – above all – an uneventful stay and a save return home!

Anonymous

Hi there, I hope, you’ve recovered from the shock? If you’re like me, you’ll want those… those… seriously punished. Of course, due to the cover-up they couldn’t discipline them as they deserved. That would have caused to much public notice. But they found means, obviously,… .

For one thing they gave each of them a… mentor. 

“Someone stole my belt…” “No Don, no one stole your belt!”

“Chris was supposed to be here but he ‘volunteered’ for toilet cleaning!” “Now Don, isn’t that nice? Doing something positive?”

Apparently Don didn’t take that all very good. He reverted to drinking… 

And then happened what made me shiver, and, ultimately, break the silence…  Don’s mood changed…

“You know what?”

“I just got a wonderful idea….” “Don? Don’t start something foolish. Again. You know what happened…”

“YES! But you will not catch me NEXT TIME. Wait until PDC 09!”

I can tell you, I was in shock. I don’t remember how I got back to the hotel. My colleagues have been wondering about my apparent paranoia ever since then. I can’t help it, I always have this… image… of … LINUX … running on my … and that of other innocent and less prepared victims… oh no, I can’t take it no longer. I had to tell you and I’m sorry I had to give you nightmares. But you have to be prepared. Someone had to warn you…

Anonymous

Despite the the cover-up, they couldn’t prevent the public revelation. They most likely simply didn’t know what Bob had in mind when he entered the stage. Otherwise they would have done everything to restrain him.

Anyway, finally he broke the silence. Not only did he reveal who was behind THE CRIME, but he also made clear how high this conspiracy ranked, if he himself knew about it…

“I, Bob M., do confess that I knew from the very beginning about…”

“Chris and Don are not bad people, really, …”

THERE! SEE! HE NAMED THEM!

“… they are just misguided, maybe hung out with the wrong people…”

HE EVEN DEFENDS THEM! 

“… we have to help them. Make them see the wrong in their doing.”

Of course this part was cut out of the official recordings of the key notes. I also couldn’t ask him personally later on because he supposedly started his vacation earlier than planned. Yeah, right. But he is still alive, I mean, they didn’t go that far… so far.

Anonymous

By the time I was left out of custody the cover-up was firmly in place. It was really spooky. Hence not many attendees may have noticed the copy cat incident…

“That hideous crime … scratch that, I’m not allowed to talk about that any longer. Anyway, I can live with LINUX. I mean, as long as I can install Visual Studio it could be running on DOS….”

“What… What is ‘Booting Linux Kernel’ supposed to mean?  … Wait! Where’s my Visual Studio? …”

  Fortunately the forensics where still around. They secured the evidence and got the machine running in no time. Real pros, I have to say.

Later the “problem” was explained as some ‘glitch’ in an early Windows 7 version. (There was some talk about a run-in, Scott supposedly had with Steven later that day, but I could never confirm that.)

Stay tuned, I’m getting closer. You’ll never believe the truth…

Anonymous