Is there anyway to customize the username which a user enters in AWS Amplify? I am creating a multi-tenant app suit in which a user may belong to more than 1 tenant. That tenant may have different authentication requirements, such as TenantSMSMFA using SMS for MFA, and TenantTOTP using TOTP.
It's possible that a user with the same email might exist in different organization, with a different account and different settings and use different apps, so ideally I would like to be able to prefix the username such as : TenantSMSMFA-usera#test.com & TenantTOTP-userb#test.com. A bit of a silly requirement but trying to avoid creating more than one user pool if I can. For example say there is a contractor who is doing work at CustomerA with their private email address as their username, and then move to CustomerB, currently CustomerB could not create their account again because it would be conflicting with an existing account.
Related
I am writing a web application that will have users outside of my company, but should not have a general "sign up" page. The flow that I am trying to build:
We send new users (customers who have signed a contract with us) a single-use link (e.g. service.com/signup?uuid=[uuid])
The link leads to a page where they set their password. This completes their account creation.
The email for the account is already defined, and connected to the link that was sent to them. For this reason, an email confirmation should not be necessary.
There is also a value for each account called "role", which is not user-facing. When we define a new user, we define a new "role" with it. The UUID of sign-up link is connected to both an email address and a "role".
My current implementation works like this:
One of our existing internal databases has a table of uuids and their corresponding emails and roles. When we want to create a new user, we add a new row with their email and "role". This triggers an invite email that includes the signup link.
The web application, which is written with React + AWS Amplify, shows a signup page built with Amplify's Authenticator UI for React. Custom JS prefills the email field and makes it not editable.
The user sets their password, and behind the scenes React calls a Lambda function to get the email address and role associated with that link. The new account is created with the email, role, and provide password. The user doesn't see any UI related to the "role" because it is only for internal use.
I am aware that this may not be the wisest way to do this. I have a feeling that new accounts should be created by us via Cognito first, and the user should be sent a link to set a password for their already-created account. I don't know the best way to do this, though, especially if I would like to keep the ability to make the signup process more complex (e.g. requiring 2FA, so the user needs to provide a phone number as well as a password and then verify it).
There are several ways I can think of approaching this set of problems, but I feel like my knowledge of AWS is not developed enough to have an instinct for the "correct" way. Is there something I should be doing differently?
I have a website named satellite.com built by AngularJS+NodeJS+MongoDB, it has an authentication system by ID & password, or third-parties like Google, GitHub. It already has many user accounts.
Now, I want to build a new website named umbrella.com, its authentication system and its database by ReactJS+NodeJS+MongoDB. Umbrella.com will include the functionalities of satellite.com (which will ideally share code with satellite.com) and some other functionalities. In the future, I want both satellite.com and umbrella.com to exist and work (though satellite.com may systematically redirect to umbrella.com/satellite/).
I wonder how umbrella.com can use the existing user accounts of satellite.com. Ideally, I hope
existing users of satellite.com could sign in umbrella.com with their old credentials, and have access to their data of satellite.com
new users could sign up on satellite.com, which will be valid to umbrella.com too
new users could sign up on umbrella.com, which will be valid to satellite.com too
I have total control of the two websites. Does anyone have a clear suggestion on how to structure and share the authentication system and the database of these 2 websites?
Edit 1: one issue is that when I set up Google Authentication for satellite.com, I remember that the domain name (i.e., satellite.com) was required. So now, can we use these authentications for another domain name (i.e., umbrella.com)?
If you are not using third party authentication like Google Auth or something where you have to specifically register your domain you can achieve that by following steps:
You can keep one database structure for both website with different
front-end. For that you user can login to both websites using same
credentials.
You can also go with one backend (Node server) for both the websites
as its seems like both are same and having same functionality.
Front-end can be different.
Our application (referred to as "XYZ_App" below) is a multi-tenant SaaS application. We are in the process of making it available for Microsoft AppSource as a multi-tenanted "Web app / API" (referred to as "AppSourceXYZ_App" below).
We started our OpenID Connect implementation with endpoints pointing to “common” as per stated in the documentation when multi-tenancy is desired/required.
In XYZ_App, we added information in the system to know what AAD instance each XYZ_App tenant is associated with (using the GUID Microsoft assigned to this AAD instance, we are NOT using the "rename-safe.onmicrosoft.com" representation).
When using the “common” endpoints, we had to manually validate the issuer from the JWT to make sure it was the expected one: a user could access XYZ_App requesting access to XYZ_App’s tenant associated with contoso.onmicrosoft.com, get directed to “login.microsoftonline.com/common” to authenticate and then decide to authenticate with a user from another AAD instance (referred to as "anotherAADInstance.onmicrosoft.com" below). In this scenario, even though a user could successfully authenticate on anotherAADInstance.onmicrosoft.com, XYZ_App’s redirect URI must make sure the JWT issuer is the one from contoso.onmicrosoft.com. I’ll refer to this setup as Scenario_1.
With that scenario in mind, we thought about NOT using “common” and customize the requests going to login.microsoftonline.com on the fly; attempting to “jail” requests to be forced to authenticate against a specific AAD instance. We would still need to perform our validation in the redirect URI to make sure the issuer is the appropriate one, but we thought this approach might make our lives easier. I’ll refer to this setup as Scenario_2.
Do you envision Scenario_2 is viable in the long run or is it too short-sighted ? Based on my current knowledge of OpenID Connect, one limitation I can see with Scenario_2 is that it would become problematic to support “broker accounts” into our app.
Explanation of “broker accounts”: in our industry, some external users are allowed access to the system. Let’s say I have a company called “BrokerCo” (with their own brokerco.onmicrosoft.com AAD instance) who has 2 employees: Broker1 and Broker2. BOTH anotherAADInstance and contoso hired Broker1 and Broker2 to get broker services to perform tasks in XYZ_App; requiring XYZApp to grant them access. What is the ideal way for authentication from an OpenID Connect standpoint ? If XYZ_App were to use “login.microsoftonline.com/common” for authentication (like in Scenario_1; as opposed to “jailed” access like in Scenario_2), Broker1 and Broker2 could authenticate with brokerco.onmicrosoft.com (no AAD "External users" for anotherAADInstance nor contoso), but they would then get to redirect URI with an issuer that is different than what XYZ_App’s anotherAADInstance and contoso tenants are configured for... I feel like I’m back to square 1...
Do you have suggestions or pointers to solve this issue ?
Background context:
While playing with OpenID Connect issuers, I got the following error message:
AADSTS50020: User account 'testuser#anotherAADInstance.onmicrosoft.com' from identity provider 'https://sts.windows.net/XXXXXXXX-fake-GUID-9bZZ-XXXXxxxxXXXX/' does not exist in tenant 'XYZ Publisher' and cannot access the application 'YYYYYYYY-fake0-GUID-YYYYyyyyYYYY' in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account.
Thanks in advance !
Your question has multiple layers, trying to address most of them:
AppSource is about trial experiences for new users: this mean that any corporate account around the globe can potentially be an user of your SaaS application - or at least to the trial experience of your application, therefore the first thing you need to think when integrating with AppSource is how easy it has to be for a potential user to experience your app for the first time.
With that in mind, AppSource recommends that the trial of application is build on such a way that allows any user from any organization to sign-in, and therefore a multi-tenant approach for your application is the recommended setup for any application.
The single-tenant approach requires more control on your side, and for a trial experience - it means that the user cannot try your application right away because the operation you have to do on your single-tenant application is to add the user to an Azure Active Directory tenant as a guest user. This guest account will need then to wait receiving an email to accept the invitation to join to this tenant you are adding the user to then sign-in to your application.
Therefore your scenario 1 is the best scenario thinking on a trial experience in general, and also in general require less management (as you'd not need to create/ manage each individual account that needs to access your application as guest users of your Azure AD instance).
However some concerns you listed - that this scenario bringing are valid: Because you are accepting the common endpoint, you are saying basically that any user can sign-in to any tenant to your application, and this may not be desirable. In addition, the scenario you listed that a user can generate a token for any application is also valid, however, you can add additional checks to make this more secure and that any token generated by another authentication is blocked:
You can validate the 'audience' claim to guarantee that the token was issued to your application
You can eventually check the 'tid'/'iss' claims against of a list of tenant Ids in your database to see if that the user's organization is a valid organization in your application -- this would be valid for non-trial users/ organizations.
More information in this article.
About scenario '2' and broker accounts:
This scenario could be interpreted in two different ways:
Broker accounts are guest accounts of a customers' Azure AD tenant
Broker accounts are third party accounts but are not actually added as a user of anotherAADInstance or contoso AD
If your case is '1' then you're right: if your application needs to authenticate guest users that belong to another Azure AD tenant, then common endpoint could not be used directly.
If your case is '2' then what you'd need to do is to continue using the common endpoint and somewhat after the user is authenticated ask them to choose the company. I am describing this on generic terms without fully understanding this scenario. Perhaps this is not simple as you want the remote company to control this and not the user - so some additional complexities may need to be handled here.
A note is that if your scenario is scenario 1. - in theory - you can still use an hybrid approach, where you'd ask user to type the username inside the application and the company that they want to sign-in, then check if you need to validate the user against common or tenant-id endpoint, preparing the request and then sending a login_hint argument when authenticating. More information here
I have two applications in my workspace, APP 1 and APP 2.
In my case, user will log in to APP 1. from there, i put a menu(or a link) to APP 2. however APP 2 requires authentication. So it will take me to a login page. i would like to eliminate that and get the current user's credentials on APP 1 and login to APP 2.
i'm looking for a simple straightforward method (but need to consider security) to login to APP 2.
what i could think of is apex_collection..i could store credentials n use it to create a login process for APP 2. however apex_collection is session based. eventhough i've set session for APP 2, it still wont read values from my apex_collection.
Does anyone have a suggestion or a solution?
All you need to do is use the same authentication scheme in both applications and set the cookie name attribute to the same value in both authentication schemes like this:
APEX will then use the same session across the two applications and the user will not have to log in again when they navigate from one to the other, provided of course that you pass the SESSION_ID in the URL.
A Few Comments on Default APEX Workspace Authentication Security
It may also be helpful to expand on an explanation of why the solution posted by #TonyAndrews works.
For any Apex Apps within the same workspace, if they use the default "APEX Application Authentication" method, they will consult the same authentication user list... so USER1 and its password is a valid login for any of the "neighboring" applications...
This may be a concern if you are hosting different clients or users that should not be intermingling with the other applications. You can also define user GROUPS in the same place as you set up each workspace user. Each application can have its own security filter that permits access by membership of BOTH user/password authentication AND membership in the appropriate access group.
Sharing workspaces may also be a problem because of the unique user name restriction of a single workspace. You can get around that by:
Defining different name-spaces for each application:
Email addresses are good: "someuser#sampledomain.com"
An app id prefix such as: SHOP_EDNA, SHOP_GARRETT, TC_KAREN, TC_MARLOWE, MY_BORIS etc.
Different name styles: first name only, first name + last initial, etc.
To keep things simple, you can always just spin up a brand new workspace: a warning however is that common user names like `ADMIN` are NOT the same between separate workspaces. There shouldn't be much concern however because apps or workspace users may have the same or different schema access privileges to the database back end.
A Word of Caution to Administrators and Developers:
When you go live with an application or multiple applications on a user-facing system, keep in mind the deployment destination (i.e., the workspace) and what else is sharing that workspace. There are some real situations where apps are not intended to be shared or accessed by other "inside" users. Be sure to read up and understand the security constraints and methods of using Default Apex Authentication security so that it's more than luck that protects your own production/live deployed applications.
I do have the similar requirement, linking from one application page to another.
Tried the above mentioned solution, but still asking to login to second application. My Apex ver is 5.0.3 and trying in same workspace.
Created new authentication schemes for each app with same cookie name and set them as current authentication. Scheme type are Application express accounts.
Setting the link as below from first app page to second.
href="http://servername:port/apex/f?p=224:2:&APP_SESSION"
Could anyone provide a solution, please?
Just an update on this.
I am currently using v21.2 and this is how I do it:
In both applications, go to Shared Components > Authentication Schemes > (Select your Auth Scheme);
Scroll down to Session Sharing and select 'Workspace Sharing';
In one of the applications (source), create a link (as a Navigation Bar List entry, for example) like f?p=173:1:&SESSION., where 173 is the target application ID and 1 is the target page.
After some research, I've found out that this feature (Session Sharing Type) is available since v18 of APEX.
I can check user in active directory, if he exist then I give him permission to open app window, but what if an application has many levels of permission? Do I create special groups of permission in active direcotry and check if user belongs to one of them? . Can application log in automaticaly, or there is always need to enter password?
Active Directory can fulfill two related but seperate functions for an application: Authorization and Authentication.
Authentication is validating that the person using your application is a valid user. If you have the user's credentials (i.e. the application prompts the user for their username and password), you can authenticate them against AD by attempting a connection using their username/password.
Authorization is what lets you determine the level of permissions a particular user has in your application. Active Directory groups are a relatively straightforward and flexible way to implement the various permissions levels. Typically, I will create very fine-grained permissions groups that represent each securable action users can perform in the application (i.e. CanDeleteWidgets, CanAddWidgets, CanEditWidgets ). Then create functional or role groups where you place the users for that role (i.e. Managers, Coordinators, Technicians, etc). Finally, you just nest the role groups into the permissions groups so if, for example, the business requirement is that Managers can delete widgets, you would add the Managers group as a member of the CanDeleteWidgets group. While this may seem more complex, it makes it extremely simple to respond to changing business security requirements (i.e. "Technicians need to be able to delete widgets" - Piece of cake. Add the Technicians role group to the CanDeleteWidgets permissions group and you're done).
As far as logging in automatically, yes, there are a number of ways you can automatically log in a user. For winforms apps, you should just be able to grab the currently logged in user and use that. For web apps, if you can use integrated authentication, you end up with the same thing. Your web server will handle the authentication piece and send over the DOMAIN\USERNAME of the user in a server header variable.