Windows Authentication for DNN3.0

Rate It (1)

Last post 01-19-2006 9:05 AM by DanBall. 456 replies.

Sort Posts:

  • Windows Authentication for DNN3.0

    12-16-2004, 12:16 PM
    • Participant
      880 point Participant
    • Gabe Halsmer
    • Member since 03-09-2004, 3:16 PM
    • Posts 176
    Tam's Original Thread has gotten a little long, so I thought I'd start a new one for DNN3.0.

    I want to "enhance" DNN to support the following use-case...

    * If a user is logged into a domain, visiting the DNN site should automatically recognize them and show menu options based on the Groups they have been assigned in their domain.

    And since DNN3.0 has the new membership provider model, this change should be a snap.

    I started by making a new class project for my custom providers. First I added a reference to the MemberRole.dll in DNN3.0's bin. Then...


    public class ADAMMembershipProvider : Microsoft.ScalableHosting.Security.MembershipProvider


    ...and wrote a bunch of code using System.DirectoryServices to access my LDAP domain.

    Now I had to change the web.config.

    This turns on Windows Authentication so that HttpContext.Current.User.Identity.Name becomes "DOMAIN\username".


    <identity impersonate="true"/>
    <authentication mode="Windows">
    </authentication>


    And this plugs in my first provider...


    <membership userIsOnlineTimeWindow="15">
    <providers>
    <add name="ADAMMembershipProvider"
    type="CustomProviders.ADAMMembershipProvider, CustomProviders"
    domain="MONORAIL"
    server="localhost:50389"
    ...
    />
    </providers>
    </membership>



    And it works like a charm. (note: I had to add "admin" as a User in my domain since DNN tries to get that user's e-mail for something)

    When I visit the site, my credentials are passed in (e.g. "MONORAIL\Administrator"). DNN asks the member provider if that's a valid user and it returns true. So it lets me into the sight. Now I only see the Home menu option because I haven't implemented a custom role provider yet.

    Okay, so now I want to tell DNN that user has a role. The Roles table has two entries...


    RoleName
    -------------------------
    Administrators
    Registered Users


    I'll pick the first as that should display the Admin menu option. And I'll just be quick and plug in a provider like this...


    public class ADAMRoleProvider : RoleProvider
    {
    public override string[] GetRolesForUser(string name)
    {
    // HACK
    if (name == @"MONORAIL\Administrator")
    return new string[]{ "Administrators" };


    However, that doesn't show the Admin menu option! Tracing the DNN code I see that it does ask my role provider for the list of roles my user has, but it doesn't use it. Security.vb compares the list of roles from my provider with what HttpContext has for "UserRoles". And "UserRoles" is empty! So the following method returns false...


    Public Shared Function IsInRole(ByVal role As String) As Boolean
    ...
    'Check with the Roles Provider
    'to see if the user has the role
    If objRoles.IsUserInRole(role) Then
    'Now check with the DNN roles to see
    'if the user has the role because
    'the ExpiryDate may have passed
    'for the user's role
    Dim strRoles As String
    strRoles = Convert.ToString(HttpContext.Current.Items("UserRoles"))
    If strRoles.IndexOf(";" + role + ";") >= 0 Then
    Return True
    End If
    End If
    ...
    Return False
    End Function




    I'm wondering if this is a DNN bug or I haven't set up something correctly. I scanned for any code in DNN that sets "UserRoles". Its in Global.ascx.vb...


    If Not Request.Cookies("portalroles") Is Nothing Then
    ' get roles from roles cookie
    If Request.Cookies("portalroles").Value <> "" Then
    Dim RoleTicket As FormsAuthenticationTicket = FormsAuthentication.Decrypt(Context.Request.Cookies("portalroles").Value)
    Context.Items.Add("UserRoles", ";" + RoleTicket.UserData + ";")
    Else
    Context.Items.Add("UserRoles", "")
    End If
    Context.Items.Add("UserInfo", objUserInfo)
    End If


    When I trace it, I never enter this code and I'm not sure how I would since I'm not using Forms authentication or cookies.

    Hmmmm, perhaps my role provider should set HttpContext's UserRoles? That doesn't seem right.



  • Re: Windows Authentication for DNN3.0

    12-16-2004, 4:06 PM
    • Contributor
      5,220 point Contributor
    • Imsoccrman
    • Member since 03-12-2003, 1:06 PM
    • Tulsa Oklahoma
    • Posts 1,044
    i am implementing similar functionality and have just delved into creating the provider... i will be working on this quite heavily soon so maybe I'll catch up wtih you and be able to help out.
    Steve Walker
    Senior Consultant
    SharePoint Forums
    SharePoint Architecture
  • Re: Windows Authentication for DNN3.0

    12-17-2004, 11:54 AM
    • Participant
      1,066 point Participant
    • shware
    • Member since 02-26-2003, 1:53 PM
    • Posts 216
    Hi,

    Great post. I too am running with a custom membership provider (as well as Role and Profile providers) - these are SQL providers.

    I ran a quick test with Windows Authentication mode and the Authenticate_Request() was being hit. Are you not hitting it at all??

    Also, I DID comment out that last check in Security.Vb / IsInRole():

    ' SHWARE - disable for now...let provider determine role membership
    If False Then
    Dim strRoles As String
    strRoles = Convert.ToString(HttpContext.Current.Items("UserRoles"))
    If strRoles.IndexOf(";" + role + ";") >= 0 Then
    Return True
    End If
    End If

    We're not using role expirations which the comments indicate would be the main reason why a role wouldn't exist in this array (which is fed from the DNN side of things in global.asax.vb / Authenticate_Request()). We rely solely on the roles coming from the provider.

    But either way, I am hitting Authenticate_Request() in global.asax.vb with Windows authentication turned on.

    Hope this helps!


    Shawn



  • Re: Windows Authentication for DNN3.0

    12-19-2004, 11:11 AM
    • Member
      40 point Member
    • dsmith1569
    • Member since 04-26-2004, 8:57 AM
    • Posts 8
    Is anyone planning to release a windows authentication provider for DNN 3?
  • Re: Windows Authentication for DNN3.0

    12-19-2004, 9:03 PM
    • Contributor
      2,500 point Contributor
    • tamttt
    • Member since 03-21-2003, 5:07 AM
    • Posts 500
    I'm working on Windows Authentication component for DNN 3.

    It's being tested in core team, and will be released few days after DNN 3

    Tam
  • Re: Windows Authentication for DNN3.0

    12-20-2004, 9:08 AM
    • Participant
      768 point Participant
    • Girlnet
    • Member since 09-09-2003, 10:02 AM
    • Canton, Michigan
    • Posts 191
    Can't wait!
  • Re: Windows Authentication for DNN3.0

    12-20-2004, 5:39 PM
    • Contributor
      5,220 point Contributor
    • Imsoccrman
    • Member since 03-12-2003, 1:06 PM
    • Tulsa Oklahoma
    • Posts 1,044
    Tam, Would this component have the same sort of functionality are the one you have for 2.1.2 ? (Role Import, Etc... ??)
    Steve Walker
    Senior Consultant
    SharePoint Forums
    SharePoint Architecture
  • Re: Windows Authentication for DNN3.0

    12-21-2004, 9:22 PM
    • Participant
      880 point Participant
    • Gabe Halsmer
    • Member since 03-09-2004, 3:16 PM
    • Posts 176

    Shawn, yes I hit Authenticate_Request. But "UserRoles" never gets set. Maybe DNN expects me to set it in my role provider. However, I'm wondering why I need too since, like you, I don't care about expiring roles. The purpose of that cookie is really lost on me.

    Hey Tam, what did you do about the UserRoles cookie? Is that a DNN bug or is there a way to get around it?
  • Re: Windows Authentication for DNN3.0

    12-22-2004, 10:28 AM
    • Participant
      1,066 point Participant
    • shware
    • Member since 02-26-2003, 1:53 PM
    • Posts 216
    Gabe,

    I'm sorta guessing here that the new admin account you created didn't exist in DNN until the first successful login. If that's the case then I'm guessing the Administrators role is NOT an AutoAssigned role so the user's not being assigned the role on the DNN side when the user's record was in DNN (UserController.vb / AddUser routine). If this is happening then that would explain an empty (or missing role) in the "portalroles" cookie.

    Of course, I could be missing something :) .

    This actually brings up a possible design issue in the membership provider integration. The system synch's a user's data upon first successful login thru membership provider BUT it doesn't synch up a new user's roles coming in from the provider. Not a problem for AutoAssigned roles but in cases of manual assigned roles (like Admins) it's an issue. I'm thinking that since it's synch'ing user data, it should also synch a user's roles between DNN and the provider. At the very least do it when the DNN record is created. Role expiration checks could still be done against the master DNN roles table with expired roles not be added to UserRoles.

    Hope this helps!


    Shawn
  • Re: Windows Authentication for DNN3.0

    12-22-2004, 11:07 AM
    • Contributor
      4,805 point Contributor
    • lucast
    • Member since 07-30-2002, 4:32 PM
    • Texas
    • Posts 961
    WooHoo Tam!

    Just what we were needing and trying to figure out how lack of it would compromise accepts for some corporate customers! ;)

    Will this be a free provider or a commercial provider?

    If commercial, price range?

    Again, excellent initial thought. Any details on functionality would be great.

    Many thanks!
    Tom Lucas

  • Re: Windows Authentication for DNN3.0

    12-22-2004, 12:18 PM
    • Participant
      880 point Participant
    • Gabe Halsmer
    • Member since 03-09-2004, 3:16 PM
    • Posts 176
    :: guessing here that the new admin account you created
    :: didn't exist in DNN until the first successful login

    Hmmm, what do you mean by "exist in DNN"? The Users table? DNN asks a
    membership provider if there is a user called "admin". And if I make my own
    provider, I could simply put in...


    if (username == "admin")
    return true;

    Now I did look at the DNN code, and it appears that if the provider says "yes
    that user is valid" then DNN will check its own Users table for that username.
    If a row doesn't exist for that username, then it create a new row for it.


    :: If this is happening then that would explain an empty
    :: (or missing role) in the "portalroles" cookie.

    Yes, the portalroles cookie is empty.


    :: This actually brings up a possible design issue in the membership
    :: provider integration. The system synch's a user's data upon first
    :: successful login thru membership provider BUT it doesn't synch
    :: up a new user's roles coming in from the provider.

    Ah ha. So this is a caching problem in DNN? Okay I think I follow you.
    I first logged into DNN as "MONORAIL\Administrator" when it didn't
    have any roles. DNN cached its role information in a cookie? Then
    latter when I added a role to that user, DNN didn't pick up on the change?
  • Re: Windows Authentication for DNN3.0

    12-22-2004, 3:21 PM
    • Participant
      1,066 point Participant
    • shware
    • Member since 02-26-2003, 1:53 PM
    • Posts 216
    Hi Gabe,


    Hmmm, what do you mean by "exist in DNN"? The Users table?

    Yes, the Users table. The existing logic in SignIn.ascx.vb adds a user to Users whenever the provider returns true from ValidateUser() and that user doesn't exist in Users. But, it doesn't attempt to pull the users roles from the provider for this new user, instead it adds any "auto assigned" roles from the DNN's Roles table. This issue the possible "design issue" mentioned in my last post - it's possible an Admin user can come in from authenticate via the provider side, but the Admin role doesn't get added because it's not an auto assign.

    Ah ha. So this is a caching problem in DNN?

    I don't think I'd call it a caching problem but instead a synch'ing issue between DNN and the membership provider. You've probably already done this but if not check out the "DotNetNuke Membership.doc" file in Documentation/Public folder. It explains what DNN is trying to do with the membership providers and why it's attempting to keep certain things in synch.

    In re-reading your orignal post I don't see anything about a Profile provider. The Profile provider handles the "extra" user info (eg, address, phones, web site, etc.). It works in conjunction with membership, but is a separate provider.

    Hope this helps!


    Shawn
  • Re: Windows Authentication for DNN3.0

    12-22-2004, 10:09 PM
    • Contributor
      2,500 point Contributor
    • tamttt
    • Member since 03-21-2003, 5:07 AM
    • Posts 500
    Hi Tom

    It's free, however source code will be available for developers only.
    Contact me offline, I don't know why email send to your email always return.

    FYI: all users, groups importing features will be provided as a separate custom module.

    Tam
  • Re: Windows Authentication for DNN3.0

    12-22-2004, 10:30 PM
    • Participant
      880 point Participant
    • Gabe Halsmer
    • Member since 03-09-2004, 3:16 PM
    • Posts 176
    Yeah I read DotNetNuke Membership.doc. But I didn't see anything in there about setting cookies.

    So, how can I get DNN to pick up new roles for a user? Does my provider need to mess around with the cookies?

    And about the Profile provider, I can't think of a reason to make my own. Our active directory domain probably has that exta user info (address, telephone, etc.) but I'm not sure what I would need DNN to do with it.

    BTW, are you THE Shawn? Or are you another core team member?
  • Re: Windows Authentication for DNN3.0

    12-22-2004, 11:40 PM
    • Participant
      1,066 point Participant
    • shware
    • Member since 02-26-2003, 1:53 PM
    • Posts 216
    BTW, are you THE Shawn? Or are you another core team member?

    Neither. Just A Shawn trying to help out and give something back to the community. Besides, I think THE Shawn is spelled THE SHAUN ;) .

    But I didn't see anything in there about setting cookies.

    I don't think it's really a cookies issue.

    Here's some workarounds I've done to keep things move forward in my testing:

    The first thing I had to was hardcode a single user id / password in the program and for that user set UserInfo.IsSuperUser = True. This lets me log in as a host admin. Gotta have that.

    Next, for the site admins that exist in my external system - I log in as them to get the DNN record created. Then log out and log in as your host account and go into the site's security roles and for the admin role go into manage users and give that user the appropriate Admin role. This gives them the site's admin menu.

    At least, that's how things are working for me.

    If you're hitting global.asax.vb (from previous posts) and the cookies are still not being set then step thru the code to see where / why it's existing. Something ain't right. Be sure the user is actually being added / exists in DNN. Be sure portalids are right.

    FWIW, all DNN core membership stuff is still very much in beta and very likely to change. I'm not counting on my hacks working with the next build(s).

    Hope this helps!


    Shawn
Page 1 of 31 (457 items) 1 2 3 4 5 Next > ... Last ยป
Microsoft Communities