We have a requirement to authenticate users of a web application deployed in WSO2 Application Server against an existing external database. We are trying using WSO2 Identity Server for this.
Our db table containing users has two columns which make a username unique, clientid and usercode. i.e. usercode is not unique by itself but clientid+usercode is unique. Also our passwords are salted with PBKDF2. So I have extended the JDBCUserStoreManager to talk to our database and am able to store and retrieve passwords in PBKDF2.
But I cant figure out how I can get the client id from the login page to our extended JDBCUserStoreManager. i.e how can I access clientid stored in users session, from inside our custom JDBCUserStoreManager? If I can get the clientid from the session in there, I can use it in the sql queries to do the needful.
Any help in figuring this out is much appreciated..
You can enter the combination "clientid+usercode" as the username at the login page. Then the authenticator will pass that combination as the username to the doAuthenticate() method of your custom userstore manager. There you can split the client id and usercode from the username.
Related
I have been trying to create an authentication in Laravel that is based on simple verification via an external services API key. The external API will provide me details like the username associated with the account a user should only have to supply an API key to login. No password, email, or username required.
Looking at Laravel's documentation it seems like using something like they demonstrate in the "Manually Authenticating Users" section may be most applicable. My problem is that this still appears to be based on a email + password credential model.
What is the proper way to modify/extend the frameworks authentication system to use an API key. If I use this manual authentication model I would be able to connect to the API and verify the user but I don't know the best way to modify it to accept an API key and username as the "credentials" for a new account (username would be coming from the API response data).
I want to Create a user screen with Two authentications (SMS and Email)
User will receive email to verify and activate his account first.
After that he set password and he will receive SMS massage to verify the password.I want to do this in Oracle apex.I have tried Custom Authentication but i didn't found fruitful, Any one have some good idea to achieve this.
after u take care of the email and sms verification, u should store that data in the data base and create a function to use in your custom authentication that verifies if the user is already validated.
put the function in shared components -> authentication schemes -> settings -> Authentication Function Name
(the function must return true or false to allow the login)
I'm not a fan of using SMS for Two-Factor Authentication, but if you must, perhaps this might demo implementation for Time-based One Time Password (TOTP) might give you some ideas: https://github.com/fuzziebrain/orclapex-tfa-demo
I provided some background information here as well: https://fuzziebrain.com/content/id/1718/
Good luck!
I have achieved this in one of my APEX project but only with the e-mail. For the sms I use it in another context but you could still do it. You will need a smtp server ( you can run one on your server ) and for the sms you will need an external provider. In your oracle database, create a table called OTP ( one time password ).
This table contains a foreign key to a user. When the user creates an account, run a dynamic action in pl/sql that will generate a random 6 digit number that will be encrypt in your OTP table. This dynamic action will also send an email to the user with APEX_MAIL. The full documentation for how to use APEX-MAIL is here and it is pretty easy to use. You can send the user the password for authentication trough email.
Create a new session user called user_na (not authenticated) and make it so that when he connects, the only page he can see is a page with a text field to enter the password he receive through email. After he enters it, encrypt it the same way you did when he created an account and compare the password in the OTP table. If they match , change his account type to user and then he will be able to access every page that you made accessible for the users.
If you also want to send an sms, I recommend using this tutorial. The sms provider have a free trial if you want to test. If you have any questions don’t hesitate to ask I can easily help you with this.
NOTE: if you don’t want to create different session_users you can just add a column in your user table named authenticated. Set it to 0 by default and to 1 when he enters the email password. Then, when he log in, check if this value is 0 or 1 to know which page you should redirect him to.
I'm trying to build a multi-tenant application using Stormpath. The stack being used is Angular + Express. I'm using the 'Directory-per-Organization' strategy to organize my multi-tenant accounts. My Login form has a 'Organization ID' form field for user to specify the organization’s nameKey.
Is there a specific format in which this field needs to be passed to the stormpath-express backend? Stormpath-Angular SDK has no mention of this. Assuming there is no specific format, I tried adding a preLoginHandler on the stormpath-express side to retrieve the org Id form field mentioned above and set a {accountStore : {nameKey : myOrgNameKey }} on the request body. This however does not authenticate against the specified organization. Instead, it tries to match against all the organizations mapped to the application. I tested this my typing in invalid random strings for Org ID field.
As an aside, Stormpath’s site (api.stormpath.com/login) too does not seem to authenticate against the specified tenant Key. As long as the username and password credentials are fine, I can type in any string in the tenant field and it seems to log me in fine.
I want the username-password credentials to be checked only against the specified organization key and not against all the organizations mapped to the application. How do I go about this ?
We use the IdentityServer3 as our central authentication provider. Now I have a general question about the IdenityServer in an enterprise environment. I try to explain it with the following example:
If a user was successfully authenticated, he get a token from the provider. The token includes the unique ID of the user.
The authenticated user send a request to a WebApi, to create a new item (e.g a new product).
The WebApi extract the unique ID from the token and creates the new product in the database. Additionally the new product was linked with the unique user ID (e.g as creationUserId).
An other user send a request to the WebApi to get all available products.
The WebApi create a database query to retrieve all products. Additionally the WebApi wants to convert the creationUserId of each product to the correlating username. But that is not possible, because username is stored in the identity database which is an other database one than the application database (e.g for the products). Are there some best practices to solve this requirement?
Many thanks for your help!
Regards
Thank you for your answers. I see only one way to realize my requirements:
--> I store the username with the userId in the application database, because a API for translating is to slow.
I'm trying to implement OpenID authentication for my site. Here's the scenario:
I want the user to be able to
login using just openId(user can just get verified by visiting openid provider. no need to create a custom account with email-password),
Via email/password (user has registered in site by filling out a form)
Attach open id(s) to his/her accounts (openids + email for one account).
Now I don't know what credentials I should store for open id. and not sure about the DB schema. Here's the database schema:
Table: Users
UserId => PK
... => Custom info. Not related to authentication.
Table: Authentication
AuthenticationId => PK
LoginId => (when custom site membership => email address) (when openId => openid unique address)
UserId => FK to Users.
Provider =>(when custom site membership => "CUSTOM") (when openId => openid provider address)
Password => filled when using custom membership. empty when using open id.
Now when a user logs in, whether by using openid/custom membership, I just look at authentication table and look for credentials and get the appropriate user. If no users exist, I create a new user and add an entry in authentication table.
The main question: Is storing Provider and LoginId (see the above comments to see what is being stored in these fields) enough for storing openid authentication? Should I store any additional data so that when the user returns I can authenticate him/her based on my saved data?
Do you suggest any other (more efficient) approach to implement this?
Thank you.
Store the ClaimedIdentifier for the openid user--not the Provider address. The Claimed Identifier is what the OpenID protocol verifies is unique for the user and also potentially provides portability across OpenID Providers.
Also, because OpenID 2.0's Claimed Identifiers may be deprecated by OpenID Connect (an unfinished successor to OpenID 2.0), it may also be in your best interest to record the OpenID Provider Endpoint URI and the email address asserted by the Provider in the user record. For now, do not use these as part of your authentication flow, but by recording them, you'll be able to later determine which email addresses you 'trust' (i.e. suppose you decide email addresses asserted by Google are trustworthy) and allow the user to thereby migrate their account to an OpenID Connect one using that verified email address. This will also mitigate against the danger of your web site's Realm (usually http://yourdomainname.com) changing and causing all your Google's user Claimed Identifiers to change, which can only really be recovered from via their email address, tragically.
I also recommend you use different tables for the different auth types. There are a couple of advantages here. The most important one is that architecturally it makes it more difficult to have introduce a security hole into your web site that might allow someone to enter in (for example) an OpenID into the username field and a blank password and have it show up as a database match and login without any real authentication happening. Secondly, it provides a more flexible model in case you want to add a third authentication mechanism rather than making your 'Authentication' table grow horizontally for all users. For example, OAuth 2.0 and "OpenID Connect" will each probably introduce new types of authentication to your site when you add support for them over the years, and adding new tables to handle the new types of data seem to fit better.
We just store the openid claim url. You may want to request additional information from the provider such as the user's name. The most important thing is to separate membership and authentication.
Our schema was
Profiles
--------
UserId
FirstName
LastName
etc.
Users
-----
Username
Password
Profiles.UserId is simply a string property that stores either the users internal username or their openId claim url, depending on how they registered.
Upon successful authentication (either using an internal username/password or external provider) we just set their authentication cookie using either their internal username or their claim url. Getting the user's profile is then just a matter of finding the profiler where (UserId == User.Identity.Name).
This has the advantage that a user can choose to change how they authenticate at any point (perhaps switching to an internal account or using a different provider).