5

I am wondering whether Silverlight has a security context where you can flag portions of the code with [PrincipalPermission(SecurityAction.Demand, Role = "Administrator")].

From all the research I've gathered so far is that in order to obtain a "user object" you have to write a service (or use the nasty RIA crap they want to complicate our lives with) and pass back and forth a custom defined user object (which inherits from UserBase object) that is recognizable by both the xaml (silverlight) runtime and the wcf service.

Assuming that this much is correct, how do i restrict access to particular screens within the silverlight app?

How do I set the current security principal to be the same as the user instance returned from the service?

I don't want to reinvent the wheel, and I was hoping I could use the authorization techniques in ASP.NET/Windows inside silverlight code by decorating screens with PrincipalPermission attribute or the silverlight equivalent.

Any help will be greatly appreciated! Thanks,

Martin

bleepzter
  • 9,607
  • 11
  • 41
  • 64

2 Answers2

1

As long as the application implements the WebContextBase object in the System.ServiceModel.DomainServices.Client.ApplicationServices.WebContext.WebCon­textBase namespace (from the WCF RIA sdk) than the security context should be valid. The WebContextBase implements the IPrincipal interface which in turn makes the usage of [PrincipalPermission(SecurityAction.Demand, Role = "Administrator")] attributes possible throughout the code.

In order to make this work, in the web project of the solution one need to add a AuthorizationDomainService, and implement either the default or custom membership & role providers.

bleepzter
  • 9,607
  • 11
  • 41
  • 64
-1

I'm not sure I understand how the PrincipalPermission stuff would help you.

Your app would have to allow the user to navigate to a screen they don't have access to before it would come into play. It would make more sense to engineer your app so that the user only gets to navigate to features they have access to.

Come to think of it instead of securing "Screens" try securing the data that is displayed on the "screens" (which you could do at the server end).

BTW the answer is no Silverlight does not support the concept of a Security Principal.

AnthonyWJones
  • 187,081
  • 35
  • 232
  • 306
  • Well, the concept of authorization is applied via the IPrincipal interface, on Windows (WPF/Forms), ASP.NET, or Silverlight. Apparently the Silverlight 4 rtm generates the `WebContext` object which inherits from `System.ServiceModel.DomainServices.Client.ApplicationServices.WebContext.WebContextBase' and has: `public IPrincipal User`, `public AuthenticationService Authentication` `public static WebContextBase Current` So on that note, I can in theory use the `PrincipalPermissionAttribute` to restrict screens since each screen is a uri right at the constructor of each screen. – bleepzter May 03 '11 at 21:39
  • @bleepzier: In theory, have you tried it in practice. How do you use a `PrincipalPermission` that doesn't exist in Silverlight? If you are using UriMapping in a Silverlight app then create a custom mapper and include your IPrinciple checking code in that. – AnthonyWJones May 04 '11 at 12:31