Wednesday, August 09, 2006
by Nik Kalyani
Wednesday, August 09, 2006 4:36:56 AM (Pacific Standard Time, UTC-08:00)

Starting with DotNetNuke v3.3/4.3, all dependencies on the Microsoft MemberRole assembly were removed. DotNetNuke includes a Role Provider, a Profile Provider and a Member Provider that works directly with ASP.Net membership. When the MemberRole dependency was introduced in DotNetNuke v3.x, many portal administrators who used the multi-portal Single Sign-On capability in DotNetNuke v2.x had to resort to third-party solutions to make SSO work across portals. With DNN v4.3 (possibly v3.3 also; I have not tested), it looks like SSO, or at least the potential for SSO is back.

If you add a row for a user in the UserPortals table, the user will effectively be able to authenticate seamlessly to every portal for which her/his user ID has a portal ID assigned. It’s that simple. Everything works as you would expect — roles are portal-specific; the user’s profile is portal-independent and authentication works regardless of which portal a user initially logs into.

Implementing a UI for administering SSO looks to be as simple as having a module where you can link/unlink users to/from portals. Nice.

Monday, September 04, 2006 1:05:34 AM (Pacific Standard Time, UTC-08:00)
I am not clear on what you mean by "If you add a row for a user in the UserPortals table, the user will effectively be able to authenticate seamlessly to every portal...". It looks to me like the aspnet_... tables are still being used in DNN 4.3.4, and there must always be entries in these tables matching the corresponding native DNN tables (aspnet_Applications = Portals, aspnet_Users = Users, aspnet_Membership = UserPortals etc).
If I want to implement a SSO mechanism that works by directly altering database data, don't I have to take into account the aspnet_... tables?
Laurence
Monday, September 04, 2006 7:33:19 AM (Pacific Standard Time, UTC-08:00)
The aspnet_ tables are application-specific. In this case, an application is an instance of DotNetNuke. Since multiple portals are purely a DotNetNuke thing, no other changes need to be made for SSO to work correctly. When you add a row to the UserPortals table, you are telling DotNetNuke that the user is allowed access to certain portals. Since this does not change the actual user in any way, no additional changes are needed.

Nik
Nik Kalyani
Name
E-mail
(will show your gravatar icon)
Home page

Comment (Some html is allowed: a@href@title, b, i, u) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.  

Enter the code shown (prevents robots):

Live Comment Preview
RSS feed
Search and Links
Bling

View Nik Kalyani's profile on LinkedIn

Contact me: nik*kalyani.com (replace "*")

TechBubble
www.flickr.com
This is a Flickr badge showing public photos from techbubble. Make your own badge here.
Statistics
Total Posts: 214
This Year: 32
This Month: 0
This Week: 0
Comments: 238
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008
Nik Kalyani
Sign In
All Content © 2008, Nik Kalyani