Remoting Authorization on the Server

Remoting Authorization on the Server

Old forum URL: forums.lhotka.net/forums/t/3031.aspx


jdorp posted on Tuesday, June 12, 2007

My company is developing an application that will utilize the Data Portal functionality of the CSLA framework.  From what we can see the only place the authorization methods (CanAddObject etc.) are called is in the Public Factory methods.  Is there anything in the Data Portal (Server Side) implementation that checks the authorization on the server after it has been checked on the client. 

If not how does this ensure that no unauthorized user can use the server with out first being authenticated?

Thanks,

Jon

RockfordLhotka replied on Tuesday, June 12, 2007

The data portal, combined with the network transport, provides the basic tools you need. Since different people have different authorization needs however, I didn't choose a specific (and thus limiting) solution to put into the framework itself.

The data portal can run in Windows integrated mode, or custom mode.

If in Windows integrated mode, it relies on Windows and the network transport to manage the user's identity, including authentication and impersonation.

If in custom mode, it relies on you to implement the authentication - but the data portal does handle impersonation for you.

In any case, what you actually do with the user's identity is entirely up to you. As I show in the book, you can use the identity to implement per-object and per-property authorization on the client. Thanks to impersonation, this same identity is available on the server too, so you can easily add similar checks (at a per-object level anyway) into your DataPortal_Insert/Update/Delete methods.

If you want to implement some broader scheme, you can override DataPortal_OnDataPortalInvoke() in your custom base class (you should have a custom base class between any CSLA base class and your actual business classes). This method runs before any regular DataPortal_XYZ methods, and you may be able to write code here to block unauthorized users, etc. (Just make sure to allow all DP calls bound for your custom principal object or else no user can authenticate!)

Copyright (c) Marimer LLC