As announced way back at CSDC 07 (http://kevinharder.com/blog/live-blogging-the-csdc-part-3/) graffiti was designed to be able to integrate directly with an existing asp.net membership store... the key is in the configuration....
So first thing is to get the membership set up... this requires several changes to your web.config on your graffiti site...
You will need a connection string in the <ConnectionStrings> section pointing to the database which has your asp.net auth tables.. it will look something like this...
<add name="Graffiti_ASPNetMembership" connectionString="server=(local);uid=;pwd=;Trusted_Connection=yes;database=CommunityServer" />
Since I am using an active community, I will go to the CS site and create the default graffiti roles... (gAdmin, gManager, and gContributor, and add you current admin to the gAdmin role)... Otherwise you need to run the script "Graffiti_ASPNet_Membership_Provider_Data.sql"; this script will try to create a new application so you really only want to run portions of it, ensuring the correct applicationid guid in order to have all logins under a single aspnet forms auth "application".
Next you need to update the "User Provider".
<add key="Graffiti::Users::IGraffitiUserController" value ="Graffiti.Core.ASPNetGraffitiUserController, Graffiti.Core"/>
and finally uncomment the included <membership />, <roleManager /> and <profile /> sections of the web.config; be sure to update the applicationName property of each by default graffiti uses "/graffiti" for the application name, by default cs uses "dev" if you want to use existing cs users, you will need the application name that exists in your aspnet_Applicaitons table.
Thats it... you should be able to log into graffiti using your existing cs users... but wait, theres more... we can now do shared authentication / single signon with a few more steps...
First, you will need to specify validation and decryption keys for all the applications you want to share logins... this goes in the web.config under <system.web> (edit the guids a bit for security)
*Note: if you are updating an existing applicaitons machine keys, you should really change the name of the "auth cookie" to prevent existing persisted logins from getting a decryption exception. This will also force all users to re-login...
As infered by the note above, we have to use the same cookie names for our applications... this is done by editing the <authentication> section of the web.config (I typically just link to the existing communityserver cookie, by changing the graffiti web.config as below)
*Note: you could redirect all users to the cs login page by providing an absolute path to the login url, the page will redirect back to the graffiti site properly; this also has the advantage of leveraging the CS registration forms and process.
and finally we need to use the same cookie name for the <roleManager> by editing the cookieName property... again I set the property in graffiti equal to the default cs value ".CSRoles" (without this step, your username will show in graffiti, but if you didn't use the graffiti login form, you would not have any more permissions on the site than anonymous, until you re-logged in).
A few items of interest... at this time it appears that graffiti lowercases all the user names, and uses that for the "ProperName" so CS users without an extended attribute "ProperName" will only see their lowercased user names, a CSModule would be a good way to keep display name in sync with this "ProperName" field. Of course you will have to use the CS membership system to edit your users; but it appears that graffitis "people" page can only be used to edit users in the local graffiti database anyways (likely the only user you will see in graffiti is admin).
I've been experimenting with this on a test server at home, and have a couple of questions:
1. I can log into my Graffiti installation using my CS username, but I need to reset the password - it won't let me in with the password I use on my live site. Is this to do with the fact that I'm running this on a different machine, and thus the passwords are being hashed differently?
2. I can only see the one user from my CS store that I've given the "gAdmin" role to. Do I need to give everybody else the "gEveryone" role before Graffiti will see them in the User Management section?
Thanks for the blog post!
For number 1... did you set your machine key in the web.config? If the root domains are the same, I recomend using the same cookie name, and passing all the logins to one login page rather than have each app handle its own logins.
As far as your second issue, note the last sentance of my post
"Of course you will have to use the CS membership system to edit your users; but it appears that graffitis "people" page can only be used to edit users in the local graffiti database anyways (likely the only user you will see in graffiti is admin)."
Sure, users will likely need to be part of a graffiti role, but this alone will not be enough... they will not show up in the graffiti admin until they have a profile on the graffiti site / database... If you want all your existing users to show in the graffiti admin, then you will likely have to insert some data into the graffiti tables.. and keep it in sync with some custom CS Modules.
I guess for #1 I will have to obtain the machine key from my web host, since there isn't one in my web.config (either for Graffiti or for CS) and it probably will have to match the one that the passwords were hashed with. Does that sound right?
For #2 - it's werid, because I *do* see two users in my user managment screen, and they're the two CS users that I added to the gAdmin role. I *don't* see the default "admin" user that would be in Graffiti's user table.
I'll do some more experimenting - I'm using the 1.1 beta of Graffiti so perhaps they've made some changes around that.