Custom Security Tables

white911 posted on Thursday, November 09, 2006

I would like to use my own tables for users and security, but I would like to use the Threading.Thread.CurrentPrincipal to check for security. I don't want to use the Security Database and Table Names

How do I go about it?

Bayu replied on Thursday, November 09, 2006

Hello,

Just have a look at how Csla handles the security and adapt it to your need.

Looking at the ProjectTracker sample you can trace the following:

- Project is a BusinessBase derivative, check the CanAddObject member:

  Public Shared Function CanAddObject() As Boolean
    Return Csla.ApplicationContext.User.IsInRole("ProjectManager")
  End Function


- this may look as if it does not use the thread's current principal, but in ApplicationContext.vb you will find the following:

  Public Property User() As IPrincipal
    Get
      If HttpContext.Current Is Nothing Then
        Return Thread.CurrentPrincipal
      Else
        Return HttpContext.Current.User
      End If
    End Get
    Set(ByVal value As IPrincipal)
      If HttpContext.Current IsNot Nothing Then
        HttpContext.Current.User = value
      End If
      Thread.CurrentPrincipal = value
    End Set
  End Property


It's even better than just checking the current thread's principal, as this code can also run in a web-context. ;-)

So, now you may wonder how the pincipal is ever set.
- then you would have to look at DoLogin member of the MainForm in PTWin (if you want to have a sample for Winforms)
- or check Global.asax (for a sample that applies to Webforms).

Either way: the PTPrincipal and PTIdentity classes manage the HttpContext's or current thread's principal, just like you would like to have it. You can implement your own principal/identity pair by implementing the corresponding interfaces. These could be made to fullfill any authentication/authorizaion requirement you have on your plate.

Good luck!
Bayu