This project is read-only.


Sep 17, 2008 at 2:40 PM
Have updated the SecurityHelper class in BlogService.Utils.Security to include helper methods for symmetric encryption and decryption. Have also created a Utils.Test project as well as tests for all methods currently in the BlogService.Utils namespace.

If I've understood the WSSE issue correctly.. Atom-enabled clients will be creating the WSSE digest in the client (and not on the server) and so we will need to recover the users cleartext password in order to verify the WSSE digest (password, nonce, and timestamp). I've created PasswordEncrypt and PasswordDecrypt methods in SecurityHelper for this purpose.

Of course once we start storing reversible cipher text... we enter the tricky world of key management.

I've created two new applicationSettings properties... ApplicationKey and ApplicationIv (for now). In theory we could have used the ASP.Net machine key - but that would mean ensuring that the machinekey is in the local web.config - and not the machine.config of a hosting provider. Also probably not a good move if one application instance is hosting multiple organisations.

I guess there's no reason why these couldn't also go into the AtomPub service document as well. And I guess we'll also need to think about how we allow users to create new keys for their installation... either from an admin interface, or installation script.

(In theory the ApplicationKey itself should also be encrypted using the one of the ASP.Net helper methods.. like ProtectSection... but this is probably ok for now).

Sep 18, 2008 at 5:48 AM
You've understood it correctly: the need for access to the plaintext password is the biggest limitation of WSSE.  However, it is better than the alternative: Basic Auth over non-ssl http.  Of coarse, most blogs use forms authentication over plain http so I digress.

We need to support basic auth for the AtomPub service for users that wish to migrate from membership provider with existing users and hashed passwords.  Hopefully these users have access to an SSL cert.

Also, OAuth for the AtomPub service and especially OpenId for the website needs to be implemented.  The OpenId is easy thanks to dotnetopenid library.

I definately want to get away from storing the password in the service.config. However, it is convienient for small sites that want to use WSSE. Maybe we leave it as an option to be chosen during installation.
Sep 18, 2008 at 5:59 AM
Do you guys see any value in supporting role provider for authorization?  Unfortunately, without some clever hacks there is no way to authorize based on role + action + resource.
Sep 18, 2008 at 4:39 PM
Yup - I agree - offering options for authentication methods during installation with a warning of some sort maybe. In theory at least, with a good application key generated during installation - we should be able to offer safe storage/encryption/decryption of passwords if needed.

Not sure about  Membership and Role providers. I've seen posts on the Subtext dev mailing list that warns that the model for the ASP.Net membership provider is for one organization to be hosted in one application domain (since the app name is set in the Web.config) which could affect BlogSvc.Net if/when it is eventually going to go multi-organization (from within a single application domain). Given the fairly clear role definitions in AtomPub - I'd be tempted to write this ourselves.. but again not sure here...

As for OpenId - that would be cool - I helped (a little) with dasBlog's implementation of OpenId for comments (also using the dotnetopenid lib) - and so as long as we ask first... there should be no problem in grabbing some OpenId bits from dasBlog. Either way, rolling in OpenId support from the dotnetopenid lib isn't difficult.
Sep 18, 2008 at 7:15 PM
I've already written OpenId support for comments on BlogEngine.Net so I have some code.  It would just need to be adapted into a ajax context with the cool selector support.
Sep 24, 2008 at 11:20 AM
Edited Sep 24, 2008 at 11:23 AM

Hi Jarrett

Just checked-out the new feature branch for MVC. 

I noticed that you've started work on the AccountController currently using the MembershipProvider.

This might be ok - but if you do want to keep a multi-organisaton site in mind - like Geekswithblogs (hosted on a single application instance)...  then there are issues here. MembershipProvider is application aware - so users are filtered based on an Application Id (set in the web.config as applicationName="/") but there's no concept of 'Organisation' in the SqlMembershipProvider or schema.

So if a single application instance was used to host multiple organisations - they would in fact all share the same Application Id (and a common list of user accounts). What's more - UserName (LoweredUserName) is constrained to a unique index on ApplicationId - so only one 'Admin' user, or only one 'Bob', or 'Alice' user could exist for the entire application across all organisations.

I'd be tempted to abstract away from the MembershipProvider - and continue with the BlogService.Services.IAuthenticateService class, and then maybe write an adapter around the MembershipProvider for now if you wanted to start with a ready baked provider.

Again not 100% sure here... maybe this is just your 'spike' to get the controller going and were planning on doing this anyway...

(also feel slightly guilty - since I'm 'discussing' more than coding at the moment... flying through Rob Conery's stuff.. along with a bunch of other MVC stuff and will try to get up-to-speed with MVC fast... :-)

Sep 25, 2008 at 7:16 AM
Duh... obviously you can ignore the post above. Have just seen that a new ASP.Net MVC project creates the AccountController for you :-(