user authentication

Mar 5, 2010 at 1:03 PM

Hey, what plans do you have for user authentication?

Asp.net membership perhaps?

Coordinator
Mar 5, 2010 at 2:31 PM

Hi snooker, right now authentication has a few options. We will be building it around a MembershipProvider at some point in the near future so that the ASP.NET client can authenticate using standard components, but for the moment we have an encrypted auth ticket pattern which the API and clients use. This area is under architectural review as we go towards our first beta, so if you have any feedback or preferences for your deployment needs it would be great to hear them.

Mar 5, 2010 at 6:36 PM
Edited Mar 5, 2010 at 6:37 PM

Just minddumping an approach I've been considering for this (two parts):

1. Consuming DAM services from our own applications GUI allowing users to search / bulk add / select for use and do common tasks near where they are working,
in editing boxes etc. This would need to tie into the rights of our asp.net membership so the assets in the DAM are properly access controlled via the (WCF?) Services.

2. More rich GUI for Asset categorization and management -- equivalent to your silverlight UI perhaps? -- which would also integrate with the asp.net membership
solution but more directly since its a subsection of an administration interface to which the editor/user of the whole application can go.
(if you have DAM Admin rights -> Show link to DAM Admin -> Show Tree or Subtree that you have access rights to).

and of course multiple users can access the same repo (for one team/company/whatever)  :-)

Regards
Snooker

Mar 5, 2010 at 11:54 PM

Whatever you do, please have another method of authentication. The auth ticket idea workfs for me.

Im planning on using this in a social networking site where rights may be based on groups/friends/friends of friends.

Beyond that, I have never worked on a project for which i found the membership provider to be suitable.

Mar 6, 2010 at 10:23 AM
l0t3k wrote:

..Beyond that, I have never worked on a project for which i found the membership provider to be suitable...

What would you say is the largest drawbacks with asp.net membership?

Mar 6, 2010 at 8:38 PM
snooker wrote:
l0t3k wrote:

..Beyond that, I have never worked on a project for which i found the membership provider to be suitable...

What would you say is the largest drawbacks with asp.net membership?

It supports only the simplest model of authorization (flat, role-based). Most times, the projects im developing have features where authorization is rights based and granular, IOW security is based on specific permitted actions as opposed to what a user's role role is. Roles aggregate rights, and have no implicit value r.e. security other than a convenient label for a group of related capabilities.

This is more flexible, and can model the current state of play in the Membership provider, as well as allow more flexibility (since the rights assigned to roles are configurable at runtime).

I also tend to aggregate users into groups, which may or may not have additional  roles defined. These are group (as opposed to site) specific. Think moderator, admin, etc. Roles in the Membership provider have a flat namespace (though you can handle this by naming convention).

The same can be the case for modules. I have an event module, for example, where i can define "participant", "organizer", "speaker" and "observer" roles. These have different rights , defined by the module, within the context of the event.