I have a user profile which is identified in WSO2 Identity Server by it's unique username and unique contact id. WSO2 already supports unique usernames but I also want to ensure that we won't have any duplicate contact ids assigned.
Is there a way that we can support uniqueness for claims other than the username?
There is no out of the box way to do this AFAIK via a configuration.
An alternate approach I can think of is to write a user operation listener that gets triggered during a profile update and can validate whether the updated unique contact id is valid.
Refer http://www.securityinternal.com/2016/08/writing-user-operation-event-listener.html to get an understanding on how to write one.
Related
I am looking to use the data that comes with Cognito as secondary key to connect to other database.Potentially, I could use username or email. However, according to the project requirement, there will be lots of concerns of using sensitive data as primary key for other database. I am looking for an alternative way to set the unique key. Wonder whether userSub can be used as unique key for each users? Or there's any other values that I can use?
When a user is created in Cognito user pools, Cognito generates a sub for each user which is unique throughout the user pool. As such, you can use the sub field as a unique identifier for your users.
Though now considering that you are using usernames for your user, the username needs to be unique and so you can use the username as well instead of the sub.
If the user pool is configured to use email as username - in this case the email needs to be unique for all the users, meaning that there can not be any duplicated email id.
Same goes for phone number if a phone number is configured to be used as username.
So, in the end it is your choice is you want to use sub as a unique identifier in your key or the username.
Im my opinion I would not use an email address as a key.
How would this affect the system if the user decided to change the email address in the future or for some reason the email address simply becomes obsolete.
The sub I think would be a decent choice to use as a key. However, whenever I am thinking about primary keys I'm always thinking a million years in the future.
Ultimately I would choose a key that will forever be unique throughout the org eliminating the possibility of any future conflicts or in your case, confidentiality issues.
I'm working on a web app where all users sign in using their Google account, using Google's OAuth2 API. I'm using ScribeJava to take care of the OAuth details.
I'm currently using the "sub" field of the user's ID token as their primary key in my database. When a new user logs in for the first time, their "sub" is stored for future logins.
I'm looking for a way for an administrator to add a user before they first log in - however, since I don't have the new user's "sub", I can't just add them to the database. Is there a way to use Google's API to look up another user's ID token (or at least the "sub" field) using their email address? Is there a better primary key that makes this easier?
Let me start by saying using the Sub id is probably a really good idea. However there is no way for you to get a users sub id from their email address. That information just isn't available until a user logs in as its part of the authentication Open Id connect claims.
Sorry but what you want to do isnt possible.
Theoretically speaking, if I wanted to base my Users database table on the Auth0 returned data and maintain a unique ID in my Users table based on the Auth0 user profile id, will I ever encounter a situation where the Auth0 user id has been changed? If so, what are the situations when a user id changes?
The simple answer here is that the User Id will not change after creation for a given user profile in Auth0. However, there are a few other factors to consider, in particular:
Namespacing userids
Account linking
Auth0 will place a connection type prefix in-front of userIds to effectively namespace just the Id part - this is done with a pipe. For example, auth0|12345 or auth0|MyCustomDB|12345 etc. You need to ensure you use the entire userId, and not just the numeric value after the last pipe. The reason for this, is to ensure there are no collisions between Ids in IdP/Datastores in which Auth0 is the Service provider, & not the Identity Provider.
With regards to account linking, if you have two separate User Profiles - each has its own UserId. When you account link, one will become effectively the "primary" or "top-level" user profile, and the other profile becomes sub-ordinated as a "secondary" identity. And you can link multiple user profiles together as a single user profile in this way, but only one shall be the primary. You could consistently account link, so for example the DB Connection remains the primary, or you may just make the most recently created user profile (with a shared "email" in common to another profile) the primary... In this situation, the "tertiary" user profiles will retain their original userId, but if you were querying for the user profile only (and not trawling the identities array for that user profile also), then the effect on the search would appear to be the userId had changed. In actual fact, this is because what was originally a "top level" user profile, is now nested inside another use profile.
Finally, and slightly orthogonal to your original question - but where you state if I wanted to base my Users database table on the Auth0 returned data, hope here you were not referring to using the Auth0 user profile userId as a primary key in say a relational database. You would be better served creating a Surrogate key (unique key with no business meaning / outside dependency) as your primary key, Then store the Auth0 userId as a separate attribute on each tuple.
Hope the above made sense, please leave comments below if still unsure.
I have one table lets say TBL1 for registering the users and it contains close to 10 columns in it.I am adding all the new users to this table.Now for doing login for those users, should I point my DAO to this TBL1 for validating the users or I need to have separate table which will deal with login part.
Just a general doubt,whats the best way to maintain information about new user registration and validating users using register information.How do you register and allow users to login to your app ? are both insert and read happens from single table or from different tables ?
Here's the logic I would use:
I would register the NEW user in the registration table like you described above
When they fill out their username n password to login, I would first check for existence of that user in the registration table or TBL1. If they exist, then use their username and hashed password they used when they first registered from TBL1 or registration table to validate against their username and password on the client side i.e in browser window.
If those two don't match, i.e if the infos from the registration table doesn't match that provided in the login form on the client side, then you know they entered a wrong username or password.
To answer your question, you do NOT need a separate table for login users if you already have a registration table. You could use that registration table to do the validation when they go to log in. You can do both an INSERT and a READ to that same registration table, NO NEED for two tables there. Hope that helps you!
It depends on your requirement of application and security concerns. Of course creating a separate table for log in information is good practice.
If you have separate table for USERNAME and PASSWORD you can set limited rights on it. So only a specific part of your application can access it. And you can allow other registration details to be accessed more frequently if you need.
You might have some service that authenticate the user. So you can give access to only authentication and resetting password services for your log in table.
Even if you need to add or change something in your registration details it does not affect your authentication process at all.
It depends on Requirement and many factors of application:
Case 1: Requirement is small database having 10 tables, then you can maintain the login and registration information in the single table - TBL1.
Case 2: Requirement is big having say more than 10-20 tables, then it is good to use Normalized Level and so Create 2 different tables for registration and login and mapped with primary key.
I am using Google OpenID for login to my website. I am using it through Tornado's built-in auth library. I retrieve email ID, first name, last name and name from the openID data. My question is can I use email ID retrieved in this way to remain unique over time - including its case? For e.g. Is it possible that a user may have email ID John.Doe#gmail.com today, but in future it may be john.doe#gmail.com? I cannot find any other field in the returned OpenID data that I can assume unique for a given user.
Update Maybe I should also add that I was hosting my website on Google App Engine before and was using its built-in login. When I migrated to Tornado based implementation, I used email ID from the old logins as the unique identifier of the users. In most of the cases that seems to have work, but recently I ran into a case where the user's email ID returned from OpenID was different from his email ID from GAE version only in case. Therefore I am trying to understand how this can happen.
Since it's an email address, you shouldn't consider case, as for normal email case is unimportant. So, you should be able to consider that unique in a case insensitive test.