I'm trying to design MVC4.5 website on Azure with latest EF but stuck in setting up membership and role base authentication.
I'm somewhat lost in MembershipProvider, SimpleMembershipProvider and ExtendedMembershipProvider.
I found that unlike SqlMembershipProvider the SimplememberShipProvider is not designed to store multiple applications (through ApplicationName and ApplicationID) in a single database and map users accordingly so that business can run multiple applications with only one database.
I hear all praises of SimpleMembershipProvider, my question is how should the database/providers be designed so that I'm able to store user's in association with respective applications in a single database. User registration info must be completely independent from same user name in other application. I also need new features of Open Authentication.
Broadly, my queries are:
Is it possible to use SimpleMmebershipProvider to differentiate between multiple applications in a single database.
I'm thinking to modify existing schema structure made by SimpleMembershipProvider to include ApplicationId column , but then how would even a custom provider that is inherited from Extended membership provider add ApplicationId against any user.
Is there any other provider available or any article that would guide in implementing custom membership provider with custom database design along with features of open authentication.
Or am I going with completely wrong approach?
Answering to the queries of BernardG
Do you want a "head" url/site, then redirect users to the proper
application, or
No, sites should not appear related nor will be redirect to other.
Do you want a user to enter into any application and
then be redirected to another one he is registered in.
Again no, each application should have it's own registration process. Further two applications can have same username but these accounts would not be related.
Can a user register into any application?
Yes.
If not, how do you limit that?
Not limiting.
What do you mean by this?"User registration info must be completely
independent from same user name in other application."
Refering to answer to point 2, if there are 4 applications with one database and a user registers for one application, he must need to register again to have access to other application. Hence for any user the sites must not appear related.
Do you want to duplicate users info into each applications?
As per my understanding of the question a combination of username and email address (considering this combination makes any user account unique) can again be stored against another application even with different profile information.
Actually I'm used to the classic membership approach used in ASP.net 2.0 and I'm missing the application Id column for separation.
If I may, I believe your question has a lot more to do with design and establishing clearly the features you want, rather than a specific membership provider, knowing that you can do about anything you want with SimpleMembership.
My questions, and I believe those are the questions you have to ask yourself before going further, are:
Do you want a "head" url/site, then redirect users to the proper
application, or
Do you want a user to enter into any application and
then be redirected to another one he is registered in.
Can a user register into any application?
If not, how do you limit that?
What do you mean by this?"User registration info must be completely
independent from same user name in other application."
Do you want to duplicate users info into each applications?
It looks to me that this is all about database(s) design, and analysis, for your real needs. Once that's properly done, the part about membership tables will be easily solved.
Related
i am making a set of applications that share a common oidc provider (in my control), where the users will be created.
One of my applications is a stateless SPA "meeting" app where you can schedule meetings with other users, and you login purely by an OIDC token.
I am having a hard time thinking a strategy about the following
Should the "user" details be stored in the meeting app after a login? So let's say user A exists in the provider, then enters the meeting app. Should i save user A in the meeting app DB?
How to handle change of user details? Let's say user A changes name to User B in the provider. Until he logs in again, all the other users see him as User A still in the "contacts" list. What is the usual practice for solving this?
How to handle deletions in the provider. I need someway to signal that "deleted in provider -> deleted in app". Should i constantly poll the provider and get any missing users, create a push system, or is this just unneeded?
Thanks a lot in advance
That's actually a very good question and rarely explained well in online articles. Hopefully the below detailed notes help you with your solution. I have answered your questions at the end.
OAUTH USER DATA
Typically the core user data such as name, email etc belongs in the Authorization Server. It contains Personally Identifiable Information (PII) and changes are audited there. This is explored in further detail in the Privacy and GDPR article.
DOMAIN SPECIFIC USER DATA
This might include fields like a user's application preferences, and you may end up with data similar to this in your APIs:
Field
Description
id
A database surrogate key for the user
subject
The subject claim from an OAuth access token, which is typically a GUID or something similar
archived
A boolean flag set to true when a user is active in the app
field 1
A domain specific value
field 2
A domain specific value
To get OAuth user data within your applications your APIs can call the Authorization Server's SCIM 2.0 endpoint as described in this User Management article.
AUTHORIZATION AND ROLES
Interestingly, roles and application specific rights could be stored in either of the above data sources. You may want to start by putting roles in the OAuth data, but for cases where they are very domain specific and change often, I have found that storing them in my own API data works best.
DOMAIN SPECIFIC USER DATA AND ACCESS TOKENS
Sometimes you need to include domain specific user data (which might include roles) in access tokens. This Claims Article explains how claims can be looked up from external APIs during token issuance. This typically involves a REST call from the Authorization Server to one or more APIs, providing the subject value for which tokens will be issued.
CONSISTENT USER IDENTITY IN YOUR APPS
A user can potentially authenticate in multiple ways, such as default password / corporate login / social login. You may need to use some custom Account Linking logic to ensure that the subject field in the access token gets the same value in all cases. This prevents you ever creating duplicate users within your application.
USER INFO CHANGES
These are typically made by end users within an application screen, and your APIs then call SCIM endpoints to update the core OAuth data. A common case is when a user changes their name and / or email, eg if the user gets married. Note that the subject value remains the same after this edit.
USER ADMINISTRATION
In scenarios where corporate assets are used, an administrator typically provisions users, either individually or in bulk. This can be done via the SCIM endpoint. In some cases administrator actions may need to save data to both data sources - eg to create a user and set roles + application preferences.
USER INFO EVENTS
Sometimes your application needs to know about a user info event, such as new, deleted or changed users. This can be managed via Event Listeners, where an extension to the Authorization Server calls back your domain specific APIs when a user edit occurs. When a user is deleted in the OAuth user data you might then update the user's application state to archived.
DATA MIGRATIONS
Finally it is worth mentioning that the above also supports migrating to an OAuth architecture or between providers:
Get a combined view of the user data before migration
Insert all existing users into the new OAuth system via SCIM
Update the combined view of the user data with new subject values
Update your domain specific data with new subject values
SUMMARY
So to answer your questions:
Aim to avoid this because it adds complexity, though in some cases you may need to denormalise for performance reasons. The OAuth user data should remain the source of truth and the only place where edits occur to PII data.
Your meeting app would need to join on the OAuth user data and domain specific user data and present a list. This would probably involve caching a combined view of the user data.
See Administrator Events above. Your API should be informed of OAuth user data changes via an event, then your SPA would get current data on the next refresh.
When implemented like this you end up with simple code and a well defined architecture. Some providers may not provide all of these features though, in which case you may need an alternative approach to some areas.
I am fairly new to coding in the .Net environment. I am having trouble finding "real-world" examples on authentication/authorization using Identity. Most examples I come across are primarily textbook examples that use the ASP .Net registration template.
I am trying to find guidance on where to look (yes, I Googled and I get very unrealistic/unusable use cases or "classroom" examples) or how to do this.
I work for a small school and I am trying to build an application (possibly Blazor - just experimenting with various technologies now) that allows both students and employees to login into a portal and view their relevant data. I have an Employee table and a Student table based on POCO classes. When I add identity to the project it creates Users and Roles tables as well.
I would like to have the "Users" table based on the Student and Employee tables - not have a separate users table. I do not want to have a "registration" option either. I would like the option for an Admin (which would fall under an "Employee") to be able to add users, but not use a registration page.
How would I implement Identity and Roles without using all the extras added? I am using .Net 5.0.
Thank you for your time and pelase forgive the English - it's new to me as well.
I understand what you're trying to do. It IS possible to Create a Custom AuthenticationStateProvider
But unless you have a VERY robust database already, I wouldn't do it. Getting the default system set up and migrating users will take at most an hour. Setting up your own custom authorization system is likely to take you MUCH MUCH longer.
Having different users in different tables is not a good design plan. They all have names, phone numbers, e-mails and so on-- put them on one table.
Hi Derrick and welcome to the community! #Bennyboy1973 is correct, in that both your Students and Employees are all "Users", so they should all be stored in the same table. To add to that response a bit, probably the simplest way for you to manage them is by using Roles, so the Students could be in one role and the Employees could be in another. By having a role attached to each, you can then use the roles as a filter in your queries and you could also restrict the access and actions each type will have based on the role they are in.
Regarding having administrators add the users to the database without public access, this can be done as well. Once you get the default identity system up and running, you can scaffold out the whole system so it can be modified, and probably the easiest way to achieve what you are after is to then modify the default registration (signup) page so that it requires the user to be authenticated to reach it, and then implement a confirmation email to activate each new account.
There are a few things with this approach that you need to be aware of as well.
Since the admin will be setting up all the other user accounts, you should modify the email confirmation chain to require a password reset at some point. The administrators can have access to the user's information as needed but shouldn't have the user's passwords.
Identity Server will store passwords in an encrypted format, and you'll need an initial user in your database. What this means is that you will have to "seed" an initial admin user into the database that you can use to sign in and get started with everything else. You'll have to research how to do this, as it isn't as simple as just accessing the database directly and adding the user and roles because of the encryption. The program you build should be designed to do this for you on either the first run or if you are connecting to a new database, using a username and password that you know. It will then store the user properly that you can use to sign in as Admin, then change the admin password. This makes the whole thing more secure.
This all sounds like a headache, but it's worth it to work through and know how it all fits together. The, as mentioned in other answers, you can migrate existing data into the database.
We have a large multi tenant business application and we want to know how Entity Framework and Authentication will fit in this design; i mean i need samples on how to use Entity Framework in this design and how authentication will be done; i see Dynamics Crm and sharepoint use Configuration(Master) Database and different databases for each tenant; how the users will be authenticated and saved;when i investigate dynamics crm configuration database, i see it contains users table; also, the tenant database contains Users table and i don't know the difference
Your question is broad and may require a lot of detail to go into. I would like to give you a simple overview.
The Entity Framework & OWIN Middleware's are one way of easing in the development effort. You choose EF when you ONLY have a object model that is similar to that of your database.
The advent of OWIN middlewares help you to easily integrate with a wide variety of authentication mechanism like Google, Facebook, Azure Active Directory etc...
Additionally, in addition to using OWIN, you will still require to build a logic around the user and tenant management systems. There will be a tenant table that contains the metadata about your tenant's [customer's].
There will be a user table that will contain your user's against tenant's. Here, each row can be identified against a tenant using tenant identifier or you can opt to use a separate table for each tenant.
The single database model is the one which is shared by all the tenant's and is belonging to the Level 4 of Multi-tenancy.
You should decide based your business specific use case whether you need to support a shared database or a dedicated database per tenant.
With OWIN, I have also written middlewares that can talk to any OAuth2 enabled IDP and get back the user into the system. It is upto the business usecases which drive the level of customization and depth of integration required and the technologies just help us achieve the same.
Please share some more specific questions or your views to discuss further
OK, so it's a badly phrased question. But it's hard to explain in a single line.
I've tried to read the Shibboleth documentation and being a newbie got out of my depth fairly rapidly. I don't really want to spend days understanding it if an expert can take half a minute to say "no chance, that won't work".
I have many groups of users, lets say (for now) that groups are different companies.
What I'd like to do is only allow users to see some fields from other companies.
For example I'm Alice in Company A and I can see that Bob in Company B has an email address bob#b.com. He can see that I'm alice#a.com
However everyone else in Company B can see that Bob has a last name and a phone number etc.
And everyone else in Company A can see my details.
To make this more complicated, lets say that Bob and I become friends and decide we want to share our information then we create a "transient" group "alice&bob". Because we are both members of that group, we can both see each others full details. (But nobody else in A can see Bob's details unless they are also friends and vice versa)
I can sort all that out in application code by querying all attributes and relationships and only showing what's relevant but for extra security I'd like to limit the disclosure of information at source.
I think I need to use attribute filters but not sure if they are able to give me this level of control. With this flexibility of being able to form relationships, will I need to build filter files on the fly and then end up with thousands of filters that Shibboleth starts to choke on because the logic is so long.
Something like the "is requester in group" filter rule :
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPFilterRequirementAttributeRequesterInEntityGroup
The answer above is quite good, but i believe that non shibboleth users will find it confusing.
The quick answer is You really don't want to do it this way, it may be possible to do but for 100% there are better tools to do it.
Ok, full version now (sorry for being too obvious i some places).
In shibboleth architecture we can distinguish two main components.
Identity Provider IdP- which holds information about users from specific organizations.
Service Provider SP - which are generally some service or protected resource, for which we can define some access rules
In your example credentials for Alice and Bob could be stored in different IdP, because they are member of different organizations/companies, or (which isn't exactly matching the whole pattern) you can have one IdP for all users, and "company" is just one of user attributes. IdP doesn't provide you any kind of api that will give you opportunity to access users attributes for any user, apart from the one that is being authenticated.
On the other hand you have your SP, which hold some super secret resources, for which you can define policies. And in which you would like to define polices for user information.
And here lays the problem, on SP side you don't have access to whole users database, that's the way Shibboleth works. You can of course treat all users information as a resource in your SP, but why in the hell would you like to use Shibboleth if you have clear access to all users credentials on you application side?
If you store all users information on you service side I believe that any well designed relational database with some kind of authentication for your service will be better than shibboleth for this job.
Hope that helped.
This is not a job for Shibboleth or for most SAML/SSO providers, for that matter. The attribute filtering you speak of is used for filtering those attributes between the IdP and SP ... which is basically saying : let service provider or "application" B see the following attributes from IdP A.
Once you transmit the attributes to the SP on the other end, Shibboleth does not (and indeed cannot) provide you with a mechanism to prevent users of application B from seeing any data that you present to them ... in fact, they really shouldnt be able to see any data transmitted by the IdP unless you are exposing it in someway via your application.
I will like to know how does Stackoverflow maintain the additional details of users logging in using open-ids? In my knowledge, the details of these users are stored in the server of google,facebook etc. (The ones whose open id is being used). How then this site is also storing info about user's points, badges, privileges etc.?
Open id Selector, the one being used by Stackoverflow, is a client side javascript library so how is this possible?
Is a separate database created? If yes, how? There is no registration even!
Please provide the details of how this is being done.
When you login, the server checks if you already have an account. If there is no entry (it is the very first login), the server will automatically create a new user and save the openid identifier.
So the next time you login, the row is already there, and Stack Overflow will recognize you. By the way, you can learn the id of your database entry by looking at your profile url.
The JavaScript openid-selector is not involved in any of this. It just is a convenience feature which allows easy selection of an openid provider. All its magic is done before the openid magic takes place.