Not sure if I'm going about this the "right" way.
In my application, I have recently had the requirement added for a second "type" of user. This means realistically I will need to route this user to a different controller than the primary type.
As a more concrete example:
The primary user of the application will be staff members. They will need to see company wide information.
Now, clients of the company will need to be able to log into the application, and see information specific to their needs (and no more).
Furthermore, there are likely to be more types of user in the future.
What is the "correct" way of designing/implementing this?
I think that, if you control the users role in the TWIG templates and showing them the only links that they could access (and, of course, protecting the routes with firewalls in the security.yml) may work.
Related
I'm tinkering around with building a rest API that connects to a database. I'm following tutorials, but the table set ups are all really basic and one of my issues has been that in the "real world" the way its done is a lot more complex and different :(
However, I'm wondering for my actual application (really small) how can I properly set up the User table?
For example, I have set the primary key to userid because that should never be changing. Is it fine to use long for the userid?
Also, is it fine to lump a bunch of things together that are related to the user.. in the User table? I know its a stupid question.. For example, I want to know if the user has signed up for the service, so isMember. Or, is the user signed up for fast service, so hasFastService. Or, should these things be put into a UserAttributes table by the userid?
Finally, I looked up UUIDs and I'm wondering where those fit in, in which scenarios, etc.
Thanks
I'll try to answer this based on my own experience of creating users table in a project recently. The things you have to take care are basically these:
Authentication: Determine your login process and things like credential fields, user types (admin/guest/normal), whether OAuth is required or not, etc. before creating the users table. For example, whether you need a username/password to authenticate or email/password or either "username or email" with a password. The modern practice is to do away with a "username" since its redundant - an email is unique and acts as a username for all intents.
OAuth: If you are giving facebook/google/twitter logins, make provisions for that in your users table. How will you determine whether the user was a normal signup or a social login signup? A field such as "login_method" or something is useful in this regard. A second field called "user_type" maybe created for identifying the type of user account: admin/guest/employee/etc.
Profile fields: Its upto you to determine profile variables. In my last project, I used a few fields like FirstName, LastName, Theme, Timezone, etc. for the profile, but your mileage may vary.
For user-ids, it is usually best to have an auto generated integer primary key which is available in all modern databases.
Needless to say, never store the actual password in the password field. Just has your password and store the has instead. When the user logs in, you can hash the user-input and compare with the user table value.
Finally, DON'T confuse the user table by including related data like clients, employees, etc. All clients are users, but all users are not clients! Keep your design flexible, so as to include all kinds of users like admins, employees, etc.
I have a website in progress where users create posts in a feed, and may have many feeds. Their profile will display a default feed of their choosing.
The 3 tables in this paradox are "accounts", "profiles", and "feeds".
An entry in profiles contains additional information about a user. This is in a separate table because it may be modified more often, and many queries use the accounts table without needing this information.
A field in accounts (profile) must reference a profile. I've done this, instead of having profiles reference accounts, because otherwise an account could exist without a profile. A profile existing without an account would be the result of a deactivated account (provided the user explicitly chose not to have their profile removed from the site).
A field in profiles (default_feed) must reference a feed. This may be changed often, and isn't needed by most queries, so this seems a sensible place for this data.
A field in feeds must reference an account; all feeds have a creator.
You may be able to see my problem already, but I'll elaborate:
I can't make an account without making a profile, which I can't make without making a feed, which I can't make without making an account, etc...
Must I give up the functionality of profiles for deactivated accounts (which wouldn't be a huge deal, but I'd like to know if there's another way), or is there a sensible trick that will allow me to solve the paradoxical nature of this relationship?
EDIT: I've realized I could simply set the default_feed field so it's allowed to be null, and have the application handle this special case (which should never happen anyway, since a feed is created with the account) with a "this user has no default feed" message. I'd still like to know if I've missed a more creative solution though.
One simple way to break the dependency is to make default_feed in profile nullable.
Start by creating a profile with the default feed set to null
Create the account that references that profile.
Once the account is set up, create the default feed with the account that has been created as owner.
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.
The application is written in Ruby on Rails but the problem I am facing is more a design matter than language related.
the system provides service to a number of users to maintain a registry. So it relates persons to things. As such it has a model called Person representing owners and it has a model called User representing those who manage the registry.
Now a new requirement has arisen to allow People to log in and be able to change personal details which it was not required for the original design.
The question is how to refactor the application to allow this new requirement in?
One easy solution is to create Users for each person who request login credentials and link user to person entity but that is not very DRY as some fields such as firstname, surname etc. are in both classes and in particular, that is precisely the data people will be able to change. Besides User and Person are stored in separate tables.
The other possibility I was considering is to make one to extend the other but having data in separated tables it makes it a bit messy. Additionally the logical extension would be User <- Person as an user is (generally) a person but thinking on the implementation Person <- User is quite a lot easier.
One last option could be to scrap User and move login credentials into Person leaving logon fields empty for those who won't log in and half of the fields empty for those just login in.
Can you think of a better solution?
You could think about how this should ideally work if you were to write the application bottom-up, and then figure out how to make a reasonable compromise between that and your current setup. Here are some generic inputs.
As authentication is involved, you need an "Identity" that can be authenticated. This can be e.g. an email address and an associated password, with email verification.
An Identity can potentially be associated to multiple "Roles" and someone authenticated with the identity can choose which role to perform, e.g. "I am now an administrator" vs. "I am now a regular site user", and the role defines the user's current rights for the logged in identity. Or if you don't need that level of complexity, you can say that an Identity is a (single) Role.
You need some tracking between possible "Rights" and the Role the user is performing. E.g. the simplest setup could be the Identity or Role has some boolean can_edit_profile or can_modify_registry properties.
Whenever a user attempts to perform an action which requires certain Rights, it is simply a matter of looking up the corresponding rights set for the Role being performed by the user, to check whether the user is allowed to proceed.
For your application this may just involve adding a 'can_change_registry' property for your user objects, and check whether that property is True for any code accessing that part of the site.
I have an ASP.NET MVC application where I need to allow to customers configure MembershipProviders based on their environment, but still be able to map that MembershipUser to a concrete User model in our database.
Membership.GetUser() will give me access to the logged-in user's Membership.ProviderUserKey. I can use this to relate to a User record. Our custom SQL provider will just return the User.Id, but AD is a different story. In that case, ProviderUserKey is an IdentityReference.
These lookups will happen very frequently, as you can imagine (although caching can assist in reducing the lookups at the database level).
I can't decide which route is better to go: Storing the SID as a varbinary or varchar column. This column would not be a primary key and would not have a clustered index. Knowing that I can index strings pretty well, and reading a SID in string format is certainly nicer than binary. Anyone willing to share how they solved such a situation?
Update
I don't know how I missed this SO question when I was searching before I posted, but it seems pretty clear that ActiveDirectoryMembershipProvider and ActiveDirectoryMembershipUser are not quite cut out for the task at hand, as they exist today.
An answer in that SO question linked the following article, where the following was stated:
The relative identifier portion of a
SID is unique relative to the domain,
so if the domain changes, the relative
identifier also changes.
Thus when a User object moves from one
domain to another, a new SID must be
generated for the user account and
stored in the Object-SID property.
However, each group and user has an Object-GUID, which will never change, even if the account is moved. Therefore, it would behoove me to use Object-GUID in my User class, and not Object-SID. Otherwise, someone's User record will be abandoned if they are moved and therefore breaking the relationship between their principal and the data they created.
Unfortunately, ActiveDirectoryMembershipUser doesn't let me get at Object-GUID. So, I'll either have to translate the SID to a GUID after ActiveDirectoryMembershipUser does its work, or create my own MembershipProvider that does everything I need on the spot. Unfortunately, this means I might have to duplicate effort already done for me by ActiveDirectoryMembershipProvider.
Microsoft stores SIDs as varbinary(85) in sys.server_principals
This is also a unique column, so it must have an index...
username is the LAST thing you want to index on.
SIDs only change in an AD when you change a user from one domain to another. RIDs are split into 2 groups - inbuilt (< 1000) and user RIDs. Pre-defined users such as Administrator, Guest etc always have the same RID.
If you want to handle movement of users etc, then GUID is the way to go.
username can be changed at any time in Users and Groups management.
this is different to the object name, which is invariant, but I don't believe is mandated unique across a forest. You can have any number of John Smith users.
I'd look into the ADSI objects. These are COM objects which should be accessible from ASP. MSDN explains pretty well. an ADSearch object can be used to return user attributes (e.g. including DN) from a GUID.
Sounds like you're making this a lot more difficult than it needs to be. What do you need a SID or GUID for? You already have a unique, perfectly readable identifier for the users account maintained in ActiveDirectory.
It's called "the username". Hopefully it's the same username as stored in your apps "user" table.
Your app just needs to know if that username successfully authenticated with ActiveDirectory. So if they successfully log in - you just store the fact that they are authenticated in your Session variables.
If they are configured to use the db user login, if successful set the same Session variable indicating that they successfully logged in.
No fancy GUIDs or SIDs ... simple.