some tenants will need their users to login using corporate identities. I would prefer to use a single-user pool for all tenants. Since the same user can be in multiple tenants, how do we identify which corporate identity to use to log the user in
We can setup the authentication type or mode for each tenant in the tenant metadata. Ex: Tenant1:CustomAuthentication. Tenant2: Azure AD, Tenant3: On-Prem LDAP etc.
In this case, when the user enters his email address or chooses a tenant (through a tenant dropdown or tenant specific URL etc...), we pick the right authentication mode and then do the redirection accordingly. On receipt of the valid authentication, we do a cross check in the User pool and then allow the user to access the application based on his rights configured through Roles & Privileges.
This way, our Tenants, Tenant Users are all on a shared / common pool and the application data can be isolated to a different data store as such.
Related
I have Auth0 configured with Social Connections > Microsoft Account.
This is linked through Client ID/secret to a Microsoft Azure Active Directory tenant in my Microsoft organisation, with an App Registration set to allow:
Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)
All users with a work or school, or personal Microsoft account can use your application or API. This includes Office 365 subscribers.
When I log in through my app, I can authenticate successfully using my personal account eg. blah.blah#gmail.com
However, when I try to authenticate with my work account blah.blah#myawesomecompany.ai, which is managed with an Azure Active Directory, it fails with
"That Microsoft account doesn’t exist. Enter a different account or get a new one.":
I thought given the Microsoft settings it would allow it connect.
How can I make Auth0 allow Microsoft authentication with other company's existing Azure Active Directory?
Also - can I configure it to limit that feature to specific companies AAD eg. those I have specifically nominated?
Is there a way to configure this without having to upgrade to Auth0 Enterprise?
I tried to reproduce the same in my environment and got the results like below:
I created an Azure AD Application:
Note that: Make sure to use common endpoint for Multi-Tenant and Microsoft accounts.
For sample I used the below endpoint to authorize the users:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=ClientID
&response_type=code
&redirect_uri=RedirectURI
&response_mode=query
&scope=https://graph.microsoft.com/.default
&state=12345
When I tried to sign-in with the personal account, the user logged in successfully like below:
And now I tried to login with other tenant user like below:
By using common endpoint, I am able to sign with personal accounts and other tenant accounts too successfully.
To limit the feature to specific companies AAD, check this blog.
Auth0 Enterprise is required to authorize tenants to the Azure AD Application.
For more in detail, refer below MsDocs:
Use tenant restrictions to manage access to SaaS apps - Microsoft Entra
Multi-tenant application with a whitelist on tenants authorized by Marshaljs
Assuming you want to use multi-tenant app to allow users from different company to sign in your application with their work account. Let's assume you create an Azure AD application in your tenant(tenantA).
Then in your app, you may set the TenantId as the tenant id so that even you created a multi-tenant app, you will only allow users in your tenant to sign in. And the sign in request may look like https://login.microsoftonline.com/{tenantA_tenant_id}/oauth2/v2.0/authorize?, with this link, you will be able to use account like user#tenantA.onmicrosoft.com to sign in, you can also use personal account which is invites to tenantA as a guest to sign in your account.
If you want users in tenantB to sign in your app with account like user#tenantB.onmicrosoft.com, then you must set the TenantId in your app as common which will make the auth request look like https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
Then when sign in the application created by tenantA with account in tenantB, you may see screenshot below. After consenting it, user#tenantB.onmicrosoft.com can sign in this application.
I'm trying to do limit access to my application using WSO2 identity server.
In summary, a contracting company will send us a list of authorized usernames and, using WSO2, we want to be able to federate access and authorize only those usernames into each application of ours.
The general setup is: my WSO2 server will act as a federation hub to various external identity providers (IdP). These IdPs will contain their own user tables with all the users of their third party company. However, only some of those users should have access to our application (to charge by user count), as demonstrated by this diagram.
So far I've been able to
login into the application using WSO2;
Federate authentication from WSO2 to the external IdP; and
I'm able to restrict access to the application with XACML policies based on the user's role.
However, all the attributes currently come from the external identity provider, so in this scenario, they would actually be in control of who has access to the application. What I want is to be able to use their IdP for authentication, and my WSO2 instance for authorization.
Could you shed some light on how to achieve this?
since anypoint platform url anypoint.mulesoft.com is publicly accessible anyone can access the resources. Is there anyway i can restrict access to my org users apart from creating access roles.
Can i create org specific url with org secific access so that others cant access?
Can put some network related restrictions?
I think you confusing two different things:
Accessing a public URL (ie https://anypoint.mulesoft.com)
Authorization inside your organization's account
You can not restrict access to a site that you don't own, it is publicly accessible and needs to be accessed by other users. It doesn't even make sense really. Would you attempt to restrict access by others to google.com or twitter.com (or their API URLs)? It is not the right approach and it is just not possible.
What makes sense however is to manage permissions inside your organization in Anypoint Platform. It means when an user belonging to your organization logs in you can manage what of the available roles are permissions that user will have. You can do that in the Access Management page. You can also create custom roles with specific permissions and teams to better organize your users.
As mentioned you are not able to change MuleSoft's main URL (ie https://anypoint.mulesoft.com), one option being to control from Access Management page, both mentioned by #aled
There are two main ways you can get what you need:
If your organization already has some MFA tool that requires you to be in your corporate VPN, you could use that MFA as the MFA for the Anypoint Platform e.g. Users will need Username/Password, connect to the VPN to be able to get access to the MFA generator/auth and then use that code to finish logging into the platform. As Admin in Anypoint Platform you can enforce EVERYONE to have MFA set up (keep in mind ClientApps authorization for your automation users)
If your company already has an Identity Provider you can configure identity management in Anypoint Platform to set up users for single sign-on (SSO). The fragments below extracted from the official docs external-identity:
After configuring identity management, you must add new SSO users using your external identity management solution and internal provisioning process. If you use the Invite User feature to add users to your organization after you have configured an identity provider, the credentials for these users are stored locally in your organization rather than with the identity provider.
Users that log in with SSO are new users to the system. If the new user has the same username as a user that already exists in your Anypoint Platform organization, the new user co-exists with the original user with the same username. Users with the same username are managed independently from one another.
I want to know if it's possible to create an Active Directory user account that confers no access or privileges to that user.. simply to authenticate a set of credentials..
As we are hybridised AD/Azure organisation, I want this 'account' to replicate to Azure through the connector.
The reason for this is that:
We manage all our users through AD so I don't want some accounts managed only in Azure.. it would be very confusing. Centralised managemnent and support is good!
The account would ONLY be used for authenticating users into Zoom via SAML2, or any another cloud service for that matter that can use Azure as an authentication service.
No capacity to access anything within our firewall.
Your ideas would be greatly appreciated.
Gus
It depends how you define "access". By default, the Authenticated Users group is able to read everything in AD, but not write. If you're ok with that, then you're done. Just create a user and don't add any access to it.
If you don't want it to read anything on the domain, then you'll have trouble. The Authenticated Users group is described as:
A group that includes all users whose identities were authenticated when they logged on. Membership is controlled by the operating system.
Since there is no way to not have a user be part of Authenticated Users, then you would have to modify the permissions on your domain to exclude Authenticated Users. But that may cause other issues for other users.
As far as I know, the most basic permissions that any user is created can also view other users or groups in AAD. If you want to turn off this basic permission, just set Restrict access to Azure AD administration portal to Yes, then the user will not have any access rights.
Go to azure portal->click Azure Active Direcotory->User settings
I am considering using OAuth 2.0 service accounts and domain-wide delegation of authority to integrate our service with Google Apps. A particular use case is:
When Google Apps customer signs up for our service, pre-provision our service leveraging the customer's existing org structure or resources (orgunits, groups, devices, users, folders, files, etc.).
When the customer's Google Apps resources change, synchronize applicable changes to our service.
I found that when using service accounts, I need to specify the email address of an authorized super user for the domain that I'm querying, like this:
var cred = new ServiceAccountCredential( new ServiceAccountCredential.Initializer( "{SERVICEACCOUNTEMAIL}" )
{
Scopes = new[]
{
DirectoryService.Scope.AdminDirectoryOrgunitReadonly
},
User = "{USERTOIMPERSONATE#customergadomain.com}"
}.FromCertificate( x509cert ) );
if I want to e.g.
Query all orgunits or groups in the domain
Query all folders owned by the organization, or folders for a specific user
Ideally, I would not want to have to couple automated background processes on our server with a specific Google Apps user, in order to keep the resources in sync with changes that the domain's admin or users might incur on the Google Apps side.
I don't want to have to specify the user. So my main question is, am I using the correct authorization model for what I'm trying to do?
My second question is more of an aside. What is the purpose of requiring impersonation to use the Admin APIs, when delegation has already granted access to the domain's resources? In contrast to the normal OAuth 2.0 authorization workflow, I don't have to authorize on behalf of the user, I just have to specify her email address. Am I missing an intent of the service account / delegated access model?
The domain-wide delegation model allows a service account to impersonate a user and thus obtain the same privileges in the domain that the user identity + set of scopes granted to the application imply.
In the case of the APIs you're calling, only a domain administrator can access those APIs. By virtue of the scope you have been granted + the ability to impersonate such administrator, you can access those APIs.
If the task were to access a single resource owned by the administrator (say an organization's calendar), it'd be possible for the administrator to share that resource with the service account and then the service account might be able to impersonate itself to access that resource. However, in the case of an entire API, which represents many collections of resources, it is not feasible to use ACLs and the only practical approach is to grant the service account the ability to impersonate directly the administrator for specific API(s).