I'm trying to to figure out the best approach to implement a completely custom membership system in MVC. Before I go any further I should state that I do not want to extend or derive from the existing membership provider models. Their design simply do not
fit my needs.
Some quick facts about the architecture I'm working with:
The main entry point to the application is an MVC 4 web app that acts as a web portal.
Several seperate Web APIs sit in a service layer for the portal app.
One of the services willl be dedicated to handling the heavy lifting for authentication.
My first thought was to create a custom controller base class that all controllers requiring authentication would inherit from, which would handle authentication logic (calls to the service, etc). After much consideration and reading, I decided this would
be an inappropriate approach as it would add coupling that could be a problem in the future.
After digging around for possible approaches, I'm getting the impression that the better way to do what I need to do would be to create a custom action filter attribute that would handle the authentication calls, etc.
I read that authorization must take place after output caching to ensure that sensitive pages are not cached and I could either inherit from the AuthorizeAttribute so it handles it for me OR make sure that I handle it myself (I snooped through the mvc source
code to see how it works in the AuthorizeAttribute class).
Am I on the right path with this idea or is there another way that would suit my needs better?
When the going get's tough, the tough outsource and take a vacation... lol I wish :(
I have an open source user account system that's a good replacement for membership. It's
here. It does all the hard things with security and is decoupled from the persistence, so you can use any EF DB you want. Another benefit is that it's claims aware.
As for authorization, you could use the built-in MVC approach (via [Authorize]) or you can graduate to a claims-based authorization mechanism, as described
here.
Your MembershipReboot looks promising. I haven't had time to look through it completely yet but from what I saw it seems it may suit my needs.
I am considering claims-based authorization because it really does seem very flexible and, considering the nature of my project, could really help with extensibility of my architecture in the future. Not gonna lie though, I'm nervous to make the transition
because claims are still relatively foreign to me and I'm not sure if I'm understanding it completely enough to put it into production lol.
Thank you very much for the suggestions Brock. Excellent help as always :)
When the going get's tough, the tough outsource and take a vacation... lol I wish :(
Thanks. Any issues, questions, feedback and/or enhancements, feel free to post to the github issues page. There are many people using it (I don't know how many for certain) but I've gotten many feature requests as well as others starting to contribute (mainly
via pull requests). So, in short, there are definetly others using it.
I have a question in regards to claims aware part of MembershipReboot and rather than starting a new thread decided to post here because it feel a natural continuation. When you say claims aware do you mean that it can issue
tokens and use them for further autnetication as well?
In our current project we need to implement Authentication that will be exposed as OAuth 2.0 provider as well. So users can create account on our website and sign in using it somewhere else as well. I've been going through a lot of documentation including,
but not limited to followink:
While there seems to be a lot of information and documentation it is still hard to figure things out. So I was wondering what should be done in order to accomplish following:
1. Allow users to create account on our website
2. Allow users to sign in to our website using other OAuth 2.0 providers like Facebook, Live etc.
3. Expose our user store via OAuth 2.0 so other websites as well as apps (iOS, Android etc.) can integrate and allow our users to sign in using their credentials.
4. Implement security with Web API.
5. Allow 3rd parties to register their applications with our OAuth 2.0 mechanism and issue Key/Secret that then can be used. Like one registers apps with Facebook, Twitter etc.
While there seems to be a lot of information out there and it is truly very hard to make sense of it all.
I have a question in regards to claims aware part of MembershipReboot and rather than starting a new thread decided to post here because it feel a natural continuation. When you say claims aware do you mean that it can issue
tokens and use them for further autnetication as well?
What I mean is that the database that manages the user accounts also stores claims for the user, so when they authenticate the ClaimsPrincipal.Current is populated with the claims from the database. If you then want claims-based authorization, you're all
set and you don't have to then load claims from other sources (profile provider, role provider, custom DB, etc.). One-stop-shopping, in a sense.
haypet
In our current project we need to implement Authentication that will be exposed as OAuth 2.0 provider as well.
That's federation and not what MembershipReboot is about. I have an open issue on the github issues page to somehow implement federation and account linking, but that's not yet on my radar given my time limitations. Soon, though... soon. :)
IdentityServer is a STS. To that end, it issues tokens for other applications. MembershipReboot is a library for doing authentication within your own application. They do similar things but in different contexts.
haypet
1. Allow users to create account on our website
You could use MembershipReboot for this, or any other database to keep track of accounts. MembershipReboot goes beyond this a bit more by providing the standard security "goo" for password storage, authentication, password resets, email account verification,
etc.
haypet
2. Allow users to sign in to our website using other OAuth 2.0 providers like Facebook, Live etc.
You could federate with IdentityServer for this, but if that's all you were using from IdentityServer then it'd be a bit of overkill. You can also use the new OAuthWebSecurity features in ASP.NET (with or
without SimpleMembership). Or you could use a standalone OAuth2 library such as
the one I built (or you can build your own).
haypet
3. Expose our user store via OAuth 2.0 so other websites as well as apps (iOS, Android etc.) can integrate and allow our users to sign in using their credentials.
This requirement confuses me. Can you elaborate.
haypet
4. Implement security with Web API.
Again, this one is too vague for me to understand or comment on.
haypet
5. Allow 3rd parties to register their applications with our OAuth 2.0 mechanism and issue Key/Secret that then can be used. Like one registers apps with Facebook, Twitter etc.
IdentityServer would satisify this requirement, as it can serve as an OAuth2 authroization server.
haypet
While there seems to be a lot of information out there and it is truly very hard to make sense of it all.
IdentityServer is a STS. To that end, it issues tokens for other applications. MembershipReboot is a library for doing authentication within your own application. They do similar things but in different contexts.
It seems that what I need is IndeityServer integrated some how into our application and overriding it's IUserRepository, IClaimsRepository etc. I wish there would be some easier to follow samples. And in fact I guess MembershipReboot can actually be integrated
together with IdentityServer to fulfill everything.
BrockAllen
haypet
3. Expose our user store via OAuth 2.0 so other websites as well as apps (iOS, Android etc.) can integrate and allow our users to sign in using their credentials.
This requirement confuses me. Can you elaborate.
This means, that same way as Facebook users will be able to sign in to our application, our users will be able to sign in to 3rd party websites and applications if they choose to integrate with us via OAuth 2.
BrockAllen
haypet
4. Implement security with Web API.
Again, this one is too vague for me to understand or comment on.
We need to make sure that only registered relying parties / apps can access our web api services and that we get access to user that is authenticated to provide better content.
It seems that what I need is IndeityServer integrated some how into our application and overriding it's IUserRepository, IClaimsRepository etc. I wish there would be some easier to follow samples. And in fact I guess MembershipReboot can actually be integrated
together with IdentityServer to fulfill everything.
Yep, this combination makes a lot of sense.
haypet
This means, that same way as Facebook users will be able to sign in to our application, our users will be able to sign in to 3rd party websites and applications if they choose to integrate with us via OAuth 2.
So I guess to make this happen, I'd sort out what protocols your clients support. If they can do WS-Federation, then IdentityServer can do this. OAuth2 is not an authentication protocol, and as such IdentityServer won't work so well in this role.
haypet
We need to make sure that only registered relying parties / apps can access our web api services and that we get access to user that is authenticated to provide better content.
Ok, this sounds more like authorization which is what OAuth2 is meant for. IdentityServer supports most of the OAuth2 flows.
magicmike201...
Contributor
2021 Points
481 Posts
Recommended approach for Custom Membership implementation in MVC 4?
Mar 20, 2013 09:41 PM|LINK
I'm trying to to figure out the best approach to implement a completely custom membership system in MVC. Before I go any further I should state that I do not want to extend or derive from the existing membership provider models. Their design simply do not fit my needs.
Some quick facts about the architecture I'm working with:
My first thought was to create a custom controller base class that all controllers requiring authentication would inherit from, which would handle authentication logic (calls to the service, etc). After much consideration and reading, I decided this would be an inappropriate approach as it would add coupling that could be a problem in the future.
After digging around for possible approaches, I'm getting the impression that the better way to do what I need to do would be to create a custom action filter attribute that would handle the authentication calls, etc.
I read that authorization must take place after output caching to ensure that sensitive pages are not cached and I could either inherit from the AuthorizeAttribute so it handles it for me OR make sure that I handle it myself (I snooped through the mvc source code to see how it works in the AuthorizeAttribute class).
Am I on the right path with this idea or is there another way that would suit my needs better?
BrockAllen
All-Star
27438 Points
4893 Posts
MVP
Re: Recommended approach for Custom Membership implementation in MVC 4?
Mar 20, 2013 09:51 PM|LINK
I have an open source user account system that's a good replacement for membership. It's here. It does all the hard things with security and is decoupled from the persistence, so you can use any EF DB you want. Another benefit is that it's claims aware.
As for authorization, you could use the built-in MVC approach (via [Authorize]) or you can graduate to a claims-based authorization mechanism, as described here.
DevelopMentor | http://www.develop.com
thinktecture | http://www.thinktecture.com/
magicmike201...
Contributor
2021 Points
481 Posts
Re: Recommended approach for Custom Membership implementation in MVC 4?
Mar 20, 2013 10:25 PM|LINK
Your MembershipReboot looks promising. I haven't had time to look through it completely yet but from what I saw it seems it may suit my needs.
I am considering claims-based authorization because it really does seem very flexible and, considering the nature of my project, could really help with extensibility of my architecture in the future. Not gonna lie though, I'm nervous to make the transition because claims are still relatively foreign to me and I'm not sure if I'm understanding it completely enough to put it into production lol.
Thank you very much for the suggestions Brock. Excellent help as always :)
BrockAllen
All-Star
27438 Points
4893 Posts
MVP
Re: Recommended approach for Custom Membership implementation in MVC 4?
Mar 20, 2013 11:10 PM|LINK
Thanks. Any issues, questions, feedback and/or enhancements, feel free to post to the github issues page. There are many people using it (I don't know how many for certain) but I've gotten many feature requests as well as others starting to contribute (mainly via pull requests). So, in short, there are definetly others using it.
DevelopMentor | http://www.develop.com
thinktecture | http://www.thinktecture.com/
haypet
Member
14 Points
18 Posts
Re: Recommended approach for Custom Membership implementation in MVC 4?
Mar 29, 2013 10:17 PM|LINK
Hi,
I have a question in regards to claims aware part of MembershipReboot and rather than starting a new thread decided to post here because it feel a natural continuation. When you say claims aware do you mean that it can issue tokens and use them for further autnetication as well?
In our current project we need to implement Authentication that will be exposed as OAuth 2.0 provider as well. So users can create account on our website and sign in using it somewhere else as well. I've been going through a lot of documentation including, but not limited to followink:
Embedding Thinktecture IdentityServer in your own Applications
While there seems to be a lot of information and documentation it is still hard to figure things out. So I was wondering what should be done in order to accomplish following:
1. Allow users to create account on our website
2. Allow users to sign in to our website using other OAuth 2.0 providers like Facebook, Live etc.
3. Expose our user store via OAuth 2.0 so other websites as well as apps (iOS, Android etc.) can integrate and allow our users to sign in using their credentials.
4. Implement security with Web API.
5. Allow 3rd parties to register their applications with our OAuth 2.0 mechanism and issue Key/Secret that then can be used. Like one registers apps with Facebook, Twitter etc.
While there seems to be a lot of information out there and it is truly very hard to make sense of it all.
Any construtive help will be greatly appreciated.
Thanks
BrockAllen
All-Star
27438 Points
4893 Posts
MVP
Re: Recommended approach for Custom Membership implementation in MVC 4?
Mar 30, 2013 04:19 PM|LINK
What I mean is that the database that manages the user accounts also stores claims for the user, so when they authenticate the ClaimsPrincipal.Current is populated with the claims from the database. If you then want claims-based authorization, you're all set and you don't have to then load claims from other sources (profile provider, role provider, custom DB, etc.). One-stop-shopping, in a sense.
That's federation and not what MembershipReboot is about. I have an open issue on the github issues page to somehow implement federation and account linking, but that's not yet on my radar given my time limitations. Soon, though... soon. :)
IdentityServer is a STS. To that end, it issues tokens for other applications. MembershipReboot is a library for doing authentication within your own application. They do similar things but in different contexts.
You could use MembershipReboot for this, or any other database to keep track of accounts. MembershipReboot goes beyond this a bit more by providing the standard security "goo" for password storage, authentication, password resets, email account verification, etc.
You could federate with IdentityServer for this, but if that's all you were using from IdentityServer then it'd be a bit of overkill. You can also use the new OAuthWebSecurity features in ASP.NET (with or without SimpleMembership). Or you could use a standalone OAuth2 library such as the one I built (or you can build your own).
This requirement confuses me. Can you elaborate.
Again, this one is too vague for me to understand or comment on.
IdentityServer would satisify this requirement, as it can serve as an OAuth2 authroization server.
Security is hard.
DevelopMentor | http://www.develop.com
thinktecture | http://www.thinktecture.com/
haypet
Member
14 Points
18 Posts
Re: Recommended approach for Custom Membership implementation in MVC 4?
Mar 30, 2013 11:37 PM|LINK
It seems that what I need is IndeityServer integrated some how into our application and overriding it's IUserRepository, IClaimsRepository etc. I wish there would be some easier to follow samples. And in fact I guess MembershipReboot can actually be integrated together with IdentityServer to fulfill everything.
This means, that same way as Facebook users will be able to sign in to our application, our users will be able to sign in to 3rd party websites and applications if they choose to integrate with us via OAuth 2.
We need to make sure that only registered relying parties / apps can access our web api services and that we get access to user that is authenticated to provide better content.
BrockAllen
All-Star
27438 Points
4893 Posts
MVP
Re: Recommended approach for Custom Membership implementation in MVC 4?
Mar 31, 2013 03:26 AM|LINK
Yep, this combination makes a lot of sense.
So I guess to make this happen, I'd sort out what protocols your clients support. If they can do WS-Federation, then IdentityServer can do this. OAuth2 is not an authentication protocol, and as such IdentityServer won't work so well in this role.
Ok, this sounds more like authorization which is what OAuth2 is meant for. IdentityServer supports most of the OAuth2 flows.
DevelopMentor | http://www.develop.com
thinktecture | http://www.thinktecture.com/
magicmike201...
Contributor
2021 Points
481 Posts
Re: Recommended approach for Custom Membership implementation in MVC 4?
Apr 06, 2013 04:51 AM|LINK
Just an additional note: I took a peek at the source for the membership reboot lib and that hashing implementation is damn sexy!
BrockAllen
All-Star
27438 Points
4893 Posts
MVP
Re: Recommended approach for Custom Membership implementation in MVC 4?
Apr 06, 2013 02:03 PM|LINK
Thanks.
DevelopMentor | http://www.develop.com
thinktecture | http://www.thinktecture.com/