Identification, Authentication & Authorization Feature

Jan 7, 2010 at 3:51 PM
Edited Jan 7, 2010 at 3:51 PM

This thread is for discussing the Identification, Authentication & Authorization Feature.  Anyone in the community with anything to contribute regarding this feature should use this discussion thread.

This first post, besides announcing the existence and purpose of this thread, is the initial Functional Spec.

Add a Tab <Security> to the main UI if and only if the authenticated user has the role of "Admin"

Provide the following Use Cases (Same as ASP.NET Web Site Admin Tool/Security):

  • Create User (user name, password, email, Security Question & Answer)
  • Manage Users (Edit/delete/edit roles from a list of users)
  • Create Role
  • Manage Roles (edit roles from list)
  • Disable role

Some initial design:

As of build 53398 (1/1/2010) the ASPNETDB hasn't been used yet as there are no rows in it. Add a default superuser (administrator/password!) with an admin role (create new role) manually using ASP.NET Web Site Admin Note) and make this part of the project at some point.

Initial Roles:

  • Admin (super user of site including security (user account maintenance)
  • Author (Content author/editor)
  • User (read only user: Same as anonymous but with possible benefits?)
Jan 8, 2010 at 4:07 PM
Edited Jan 8, 2010 at 4:10 PM

Initial Design of Identification, Authentication & Authorization Feature


Extend SilverlightHVP.Web.Services.UserRegistrationService.cs  (The DomainService for UserRegistration) using System.Web.Security.{Membership,Roles} to extend that WCF RIA Domain Service and then use these added extentions in the SilverlightHVP Silverlight Client which will now be reflected in the UserRegistrationContext.

Build out user friendly User Interface using UserRegistrationContext.

Provide and run unit tests.

Server Design

Modify SilverlightHVP.Web.Services.UserRegistrationService.cs to provide the follow:

  • ·         CreateUser(strings username, password,email,passwordQuestion,passwordAnswer)
  • ·         DeleteUser(strings username)
  • ·         UpdateUser(strings username, password,email,passwordQuestion,passwordAnswer)
  • ·         GetUsers()         // returns IEnumerable<RegistrationData> // currently throws NotSupportedException ==> Implement
  • ·         AddUserToRole(strings username, roleName)
  • ·         CreateRole(string roleName)
  • ·         GetAllRoles()     // returns  IEnumerable<String>
  • ·         DeleteRole(string roleName) // this will either remove all users from role or throw exception if any users on currently in that role  TBD??

Implement using appropriate methods from the System.Web.Security.{Membership,Roles} classes available on ASP.NET Web Server applications.

Client Design

Use new functionality added to UserRegistrationService now reflected on client side in UserRegistrationContext

Provide a MEF'able View/Security(navigation Page)  that will display in ContentFrame if and only if user is authorized by virtue of being in admin role and has selected <Security> from menu bar.  <Security> button will only be visible if user is authorized and in admin role.

Security View will have a tabbed interface with 2 tabs: Users and Roles

Each tab will provide a list of Users or Roles in a datagrid to display all users/roles

To edit a user/role, select such from datagrid which will cause a modal form to display with all fields prepopulated, using WCF RIA services validation and with <Update> and <Cancel> buttons to dismiss modal.

To delete a user/role, select such from datagrid and confirm with "Are you sure?" dialog

To create a user/role, a <Create> button will be on each Tab and a modal with the appropriate form will be displayed.

Unit Test



  1. Probably should add <membership ...> to web.config because Best Practice is to set applicationName to /SilverlightHVP  (see scott gu blog)

Open Questions

  1. How do we want to handle password reset/retrieval if at all?
  2. Do we want to allow any personalization other than friendly name 
  3. Should the tab be <Security> or <Administration> or <???>

Any feedback is greatly appreciated.  Coding starts now!


Jan 8, 2010 at 6:42 PM


This is terrific, thanks! 

The HVP Project's Scope

One point of clarification; the HVP project shouldn't provide a built out database - or for that matter, any of the back end.

 In fact, I understand there is a group working on providing a back-end who will be revealing what they have in the next few weeks.

What I think the HVP does want to provide is everything you are talking about, with a "demo" or "mock" database to support it so that back-end providers can build out based on what you are building.

Using the Standard ASP.NET Model

Thus, to be clear, what I see you doing is creating enough of the ASP.NET standard back end to test and prove the client side code, but not implementing (or requiring) a specific back end except as is implied/specified by the standard ASP.NET security model.  Have I said anything different than what you are saying? I don't believe so, but let me know if you disagree.

Thus: Serverside: "CreateUser, Delete... " yup.  "Implement using appropriate methods from the System.Web.Security.{Membership,Roles} classes available on ASP.NET Web Server applications." - Exactly.

Client Side

On the client side, everything you said sounds just right though I would recommend that whatever we do with the UI for the rest of the product, the UI for your secuurity view should have a "sketch-view" appearance to it, something not unlike  this in appearance.

Let me know what you think.


Jan 8, 2010 at 6:43 PM


Can I also ask you to be sure to take the work you are intending to do and to break them into Kanban cards. Feel free to assign them to yourself (the way to do that is to take the first into your swim lane, assign the others to you, mark them blocked pending your availability, and put them into the backlog).


Jan 8, 2010 at 7:11 PM

Server Side

Jesse, as you know since you literally 'wrote the book', ASP.NET membership uses a provider model therefore, YES I think we are on the same 8*) 

That said, we do need to code up a role that will allow access to the security feature.  Maybe the thing to do is to allow anyone, including anonymous, to be an admin until a role is created called 'admin' and someone is added to it.  AND, maybe NOT hardcode 'admin' but place that setting in ASP.NET Application Configuration:

Name: adminRoleName:

Type: string

Scope: Application

Value: "admin"


Client Side

My understanding it there might be a crack team of Blenders ready to descend on this project and create a UI that rivals the best.  So I assume that I, and all patch UI work, should be kept simple, standard, and default so that the designers (black turtlenecks or whatever) can do their majic and make HVP sparkle.


I thought all this work came under the Identification, Authentication & Authorization Feature feature card.  Am I mistaken on that?

Jan 8, 2010 at 7:25 PM



Thanks for the fast response.

Server: yup

Client: If it were me, I'd have it all work, and have it make the assumption that there will be a database (we need, if nothing else to be able to demo it). I think the normal way to work admin is to have whoever sets up the system set themselves up as admin and then they have access, but I'm okay with having the page open until the user closes it. 

Kanban: the goal is that there is a card for each "chunk" of work, so I'd probably create one for the bit of back end work, and one or two for the client side work depending on how you see it breaking down.

Design: I don't yet have a full commitment for who will be doing it, but yes, we coders should be very generic.



Jan 14, 2010 at 4:52 PM

In Response to Jesse's "Severely Decoupled Configuration" blog entry from 1/11/2010 and related to this feature:

Might we also need an event to keep all the modules concerned about Authentication updated?  Perhaps something like UsersRoleChanged(string []roles)??

Use Cases

1) application starts up; fire event UsersRoleChanged(null) which indicates not logged in e.g. role is public for anonymous)

2) user logs in: fireUsersRoleChanged(array of roles for this user)  e.g. (admin, content author, content viewer)

3) user logs out: UsersRoleChanged(null)