I am working on a solution in which we are securing Hadoop echo system and its components.
My use case is I want to Authenticate the user from its AD and these ADs can be multiple. in short, this is a multi-tenant solution and each tenant or customer have their own AD so how can I link OpenLDAP with multiple AD
NOTE: There is no trust relationship needed between the ADs. means a user must authenticate from its own AD not any other.
Assuming you've considered the possible security implications of doing this (i.e. ensure CustomerA cannot adversely impact CustomerB) as well as potential customer unease (I've had to maintain completely separate servers to house different customer directories because clients were uneasy about having the service running their partition on the same machine running some other customer's directory service) ... Referrals should be able to do this -- different OUs in OpenLDAP would refer out to the various AD environments. You may need to configure an option within your application to follow referrals.
Related
I'm adding an external identity provider, Azure multi-tenant, as a login option. I have local accounts right now and they know nothing about Azure AD users.
I want to create an Azure Enterprise App that other tenants can use to set up SSO using OpenID Connect. Also I want the app to support User Provisioning by setting up a SCIM API.
I can't really find any documents on how to handle linking Azure AD users with the existing accounts in my IDP. I've seen examples where users can login using their local account, authenticate with Azure, and then their local account is updated to have the Azure AD User ID. This approach still seems pretty manual. Another thought was to have a step in the login journey, where if no local account has the Azure AD User ID then find a local account with the same email. I don't like this approach either since the emails might not always match. Is there an approach where an admin can automatically link all accounts with a sync or upload?
SYSTEMS
First it's worth clarifying roles:
Role
Details
Authorization Server (AS)
Your UIs and APIs receive tokens from this. It is where accounts and linked accounts are stored. It is where you use SCIM to update account records. It is where you apply account linking logic.
Identity Provider (IDP)
There can be multiple of these. When your apps call the AS it manages connections to them, and exchanges IDP tokens for AS tokens that are returned to apps. It is not usual to use SCIM against an IDP.
You are using IdentityServer as the AS so your UIs and APIs will continue to use IdentityServer tokens and remain simple. Meanwhile Azure AD will become an alternative IDP. So on the data side of things your architecture is in a good place.
AUTHENTICATION ACTIONS
I would aim to solve your problems via custom authentication actions, and to design this in a vendor agnostic way. Not all providers support these concepts, but IdentityServer has some pretty good extensibility features, so hopefully it has what you need.
A bit of code, configuration and technical investigations in IdentityServer feel like the correct direction, with no complexity added to your applications. I will describe techniques in terms of Curity (where I work), but the same principles can apply to any system.
USERNAME AUTHENTICATOR
A great way to deal with user specific differences is to make the initial screen prompt only for an email. See this example for how that looks. Later, when authentication has completed, you could set a cookie so that this screen is not shown on subsequent logins.
Then, before asking for credentials, apply some scripted logic, eg to look up existing account attributes, and decide how the user should authenticate. You might decide to route unknown users to Azure AD or do something based on business partner email suffixes.
DATA UPDATES
Something simple that might work in advance of adding Azure AD support is to assign all users a Tenant ID, and perhaps existing users get a Tenant ID of 1. Only those users are allowed to sign in with Identity Server - all others have to use Azure AD.
SCRIPTED LOGIC AND ACCOUNT LINKING
For a worked example of how this looks, see this Account Linking with Facebook tutorial. In this example the objective is to update the main account with a new linked account. This account linking doc may give you some additional ideas for your scenario. It should be possible to run custom logic before triggering authentication or once your have the Azure IDP attributes.
INVOLVE THE USER IF NEEDED
It may also be useful to present a custom screen to ask the user if they have an existing account when they first login via Azure AD. If not then an Azure AD login can create the primary account in IdentityServer data in addition to a linked account.
USERS AND PARTNERS
How users onboard is interesting, and discussed in this detailed article. I always start by getting a feel for the type of assets involved:
Type
Description
Personal Assets
You allow any user to sign up and they only have access to their own assets
Corporate Assets
Users are provisioned by an administrator, eg a banker is granted access to financial data according to business rules
In your case it feels like users are from the second category, so to enable a user to fully sign up you need data from the partner, either fed in manually or by getting them to call your API, before you can assign the user the correct tenant ID. This might eventually result in TenantID=23, but there is nothing to stop you initially allowing users to onboard and placing them in a default TenantID=0 bucket.
Ultimately this all comes down to data, claims and API authorization. Eg APIs could return certain data to TenantID=0 users but only return privileged data to users whose tenant ID has been asserted by an administrator. Not sure if these thoughts of mine match your scenario but hopefully they provide a useful hint or two.
SUMMARY
Reliable account linking is tricky, but it should be solvable via the building blocks of the Authorization Server, using the above techniques. The end result should be deterministic user data, with no duplicate users.
I am reading this docs that talks about security for a multi tenant application. https://learn.microsoft.com/en-us/azure/architecture/multitenant-identity/.
Let's say that my application is Tailspin. At least 2 companies, Contoso and Fabrikam, decide to use my application.
Those are my questions
Do I need to create a tenant for each customer that decide to start using my service?
Let's say Fabrikam already use a provider other than Azure Active Directory. If Fabrikam wants to use Tailspin, am I going force them to create a tenant?
EDIT
This short video shows how to start using Slack.
The first person to join Slack will enter all the information to create the space.
After that, that person will enter emails, inviting people to join the organization in Slack.
What I have noticed is that, they invitees don't need to belong to an organization [tenant] as they can have gmail, yahoo, etc. Yet, when user is logged in a space, he/she only sees what's in user's space.
I don't know how slack works, but if you have to implement something similar using Azure Active Directory as Identity provider:
Are you going to create a tenant for each customer [you said I shouldn't do that]
Should I create a security group for each customer that join so that its members can be part of that group?
Thanks for helping
You shouldn’t create a separate tenant for these companies. if in case those companies are hosted on different Identity provider. You can federate those Companies identity provider with your application IDP, and you will be accessing the application from their company’s identity itself.
Note: Your application should have capabilities to Federate with other IDP.
You can refer this document how to Microsoft federate with other IDP.
Note: For multi-Tenant, tenants share physical resources (such as VMs or storage), each tenant gets its own logical instance of the app.
For Single Tenant Architecture where each tenant has a dedicated physical instance
Problem statement
I need to make finding all the available active directory groups and their relationships in a tree and forest structure for each an every enterprise application held on an AD Domain Server easy to identify and understand by business user and technical users via an Existing IT Service Request web based application.
What I am hoping to achieve as an outcome is:
Knowledge of an API that I can connect to extract this metadata from and synchronise with the IT Service Request Application
Knowledge of what metadata AD Domain Servers are capable of providing
Knowledge of how to connect and synchronise the meta data from the IT Service Request Web based Application without compromising security
You didn't say which language you want to use. I will assume you will use one of the .NET languages, since that is by far the easiest to interact with AD.
To read the Active Directory Schema, you can use ActiveDirectorySchema.GetCurrentSchema(). That will return a ActiveDirectorySchema object that you can use to read much of the information you would want to know. There are example for how to use it here.
For your 3rd point: to read this data you have to be authenticated as a user of that domain (or a trusted domain). Authentication is already built in. When you use ActiveDirectorySchema.GetCurrentSchema(), for example, it uses the credentials of the current user to authenticate.
I have build a web application based on Azure. I have a web api service as backend and angularjs as frontend hostet in Azure.
I want to create a login page with individual user accounts. After some reading I found different user authentification strategies. Some use SQL database for managing user accounts. Some use Azure Active Directory. When I have to use Azure AD and when SQL databese?
my opinion is to compare what the benefits you will get
Azure AD:
https://azure.microsoft.com/en-us/documentation/articles/active-directory-whatis/
For IT Admins, Azure AD provides an affordable, easy to use solution
to give employees and business partners single sign-on (SSO) access to
thousands of cloud SaaS Applications like Office365, Salesforce.com,
DropBox, and Concur.
For application developers, Azure AD lets you focus on building your
application by making it fast and simple to integrate with a world
class identity management solution used by millions of organizations
around the world.
Azure AD also includes a full suite of identity management
capabilities including multi-factor authentication, device
registration, self-service password management, self-service group
management, privileged account management, role based access control,
application usage monitoring, rich auditing and security monitoring
and alerting. These capabilities can help secure cloud based
applications, streamline IT processes, cut costs and help assure
corporate compliance goals are met.
Do it yourself with your database,you will have to do all above yourself e.g SSO with Office365
So you have to ask yourself what your app does? and choose the approach fits your needs
The application managing its own user accounts in SQL is called forms based authentication. It's how most internet applications used to work, but it came with a lot of downsides.
Users had to remember a password for each site, but often reused passwords across multiple sites. If one site got hacked and lots the password database, user's accounts on other sites could become compromised.
To prevent this, sites had to make sure that they stored passwords correctly (salted and hashed with a slow algorithm) and apply other kinds of operational security to protected the database.
Then token based authentication came along which let applications delegate the authentication piece to an external 3rd party. This allows users to log in to multiple apps with the same username and password.
Most of these 3rd party login providers like Google, Microsoft, Facebook etc. have specialist working on these services and are therefore more likely to be secure than anything you create yourself.
So, unless you have really good reasons not to, I would recommend using a 3rd party login provider like Azure AD and possibly others.
We are going to use the Active Directory module to sync our users. We are still debating on whether to maintain roles within Sitecore or AD. We have had performance issues in a previous implementation of Sitecore when syncing with AD, so that makes us a little hesitant to have roles in AD. We will be creating an OU for users who need to be in Sitecore.
What is the recommendation from Sitecore regarding users and roles and AD?
Would keeping roles within Sitecore make sense and users in AD to see if that would make a difference in performance?
If we decided to have roles within Sitecore now and then move to AD later, would that be possible? How would security on existing items be affected?
Thanks
In my implementations of the AD module, using indirect membership (role in role in role in role) has performance implications. If you have a direct membership (User A is in Role B) model, I have not seen many performance issues unless, as #Patrck Perrone mentioned, you are using filters that pull back a massive number of users.
My typical recommendation for folks who are not sure which direction to go with their security is to use AD groups to manage your users belonging to specific roles, and then map those AD groups as members of the Sitecore roles. In that way, you can secure all your content to Sitecore roles, and your users will automatically gain access via their AD group.
Example:
In Active Directory: User Jay => Member of AD Group 'nonlinear\Sitecore Authors'
In Sitecore Roles: 'nonlinear\Sitecore' is member of 'sitecore\Author'
In Sitecore content: 'Home' item workflow secured to 'sitecore\Author'
In the above example, all users who are sitecore\Author members will be able to work on the Home page. User Jay, when added to the AD Group 'nonlinear\Sitecore Authors', will gain this access due to the relationship defined between the roles.
The benefit here is that if AD goes down, or you decide to stop using the AD roles, you don't have to re-apply security to your content. You would just start adding your AD users directly to sitecore\Author.
This is also helpful for local developers or offline developers working locally on their laptop who do cannot connect to the active directory repository. They can still setup all the content security and test with local Sitecore domain users while disconnected from AD.
The performance issues I have seen in the past with AD syncs were due to the query against AD returning vast amounts of data. I recommend you create a dedicated OU for security groups (and users if you are lucky enough that your organization can support this) related to Sitecore. Think of these security groups as Sitecore roles and assign AD users as members to these security groups accordingly.
On the Sitecore side, you should still use roles. Only, instead of assigned users from AD you will assign security groups to those roles.
This will allow you to continue to authorize groups of people in Sitecore per role, while delegating the task of maintaining individual membership to roles in AD where it typically should remain.