This project is read-only.

Application Authorization and Calcium

Feb 13, 2010 at 10:45 AM

I see that you added my suggestion for user role support to your list of things to consider for the future--thanks. I have some additional thoughts:

  • ·         One facet of role based functionality would be to avoid the unnecessary loading of modules if the current user does not have the right to run the module, as you have noted. But, if left here, it may not satisfy the requirements of the application. Depending on the granularity of a "module", it might be possible for a given user to have access to the module but only certain functionality within the module. In this case, the module should load but access to functionality should be limited base upon role.
  • ·         If we accept the first point, then there are likely different methods of implementation but please entertain an old man's thinking for one possible solution:
    • o   All authorization of the user should be in harmony with the use of IPrincipal to identify a user and the roles that a user is a member of.
    • o   The authorization of a user and the establishment of a user's roles should be done via application code, not Calcium per se. Calcium should facilitate this activity but the actual authorization process may likely need access to some data store unique to the application to complete this task.
    • o   Once the user is authorized then Calcium can use standard structures for role based Calcium behavior although there would need to be a way to enlighten Calcium as to behavior/role requirements. For example, the Calcium Module Manager may be required but the "view"  of the Module manager may be role restricted.
    • o   I think, for the most part, that the module initialization logic should control much, if not all of the user access to functionality not, Calcium per se.
    • o   I like to think of a module as something that would likely be a top level menu item i.e. "File, Edit, ModuleA, ModuleB,...". In a database there could exist the definition of roles, users and what roles they participate in as well as structure to define Menu structure and the required roles that the user must participate in to access the functionality. All modules might load at initialization but WPF Commanding (i.e. CanExecute)  would prohibit access to functionality that the user should not have. Yes, the menu items would still show but grayed out. This approach does require some additional thought since there may also be times when we don't want the module to load at all.
    • o   The point of all of this is to establish the fact that the application should establish its own requirements, not the framework however, there still needs to be framework support.
    • o   All of this needs to be looked at in terms of toolbar support as well. This would likely be a tougher nut to crack.
    • ·         Another thing to consider is when the user is expected to login and whether the user should be able to log out and back in without exiting the application(probably not).


Sorry to ramble on about this but I thought it important to give you my views concerning requirements for user/role based support and at the same time show some of the division between framework support and application responsibility. I'm not well versed in WCF, so I don't know how this would impact the Calcium messaging support. I hope this gives you food for thought and will help to stimulate your thinking.

May 12, 2010 at 10:38 AM

Hi Daniel,

If/when you do module auth, I would like to chip in:

  • Need to consider apps which need to work with windows authentication to SCF service, but be able to use other authentication if that's not possible
  • Please consider the P&P Entlib as the foundation upon which to build configurable authorization




May 13, 2010 at 3:38 AM

Hi Matt,

Thanks. I'm currently travelling abroad at the moment. I will look at this when I get back.




May 13, 2010 at 4:01 PM


I received this email from you but I think you addressed it to me by mistake. I'm sure Matt will welcome a reply when you have a chance to address this issue.


From: DanielVaughan []
Sent: Wednesday, May 12, 2010 10:38 PM
Subject: Re: Application Authorization and Calcium [Calcium:85247]

From: DanielVaughan

Hi Matt,

Thanks. I'm currently travelling abroad at the moment. I will look at this when I get back.



Read the full discussion online.

To add a post to this discussion, reply to this email (

To start a new discussion for this project, email

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at