Context
A company that uses Active Directory for a long time. Previously, admins added Domain Users Group to many resources with read access. It is not realistic to change all this.
A service, in this case a GitHub:Enterprise instance, that uses LDAP for authentication was introduced for a cooperation project with another company.
Problem
Creating AD accounts for the external users gives them access to many resources which they should not have access to. If we don't create AD accounts for them, they cannot access the new service.
Is there a way to create a kind of 'decorated' proxy for AD that has some local users (the external guys) and refers to the original AD db for other users (the employees)?
What other ways are there that could solve the access permission problem?
It is possible to set up an additional VM with either Windows or Linux to solve the problem; however, it would be preferable if that was not required.
Typically this would be done with SAML federation.
Or you could use your openLDAP and add all the users into it as this would not allow permissions for AD.
Related
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
We are developing a self registration app.
Our app allows users to register for web apps and is deployed on a weblogic 10.3.5 app server. The weblogic is connected to a local ldap system.
Once the user registeres with our app we call corporate servces to generate a user id. password activation, authentication is all handled by the corporate servcies. which also has a corporate ldap that contains all users in the company.
The approach works fine for 'new users' ie users that are not present in the corporate ldap or the local ldap: users enter their details and are issued a user id which we then copy into the local ldap once the user activates their account.
The use case we're grappling with at the moment is how to handle 'existing' users that wish to register. These are users that are currently in the corporate ldap and wish to 'register' with our applications. They get rejected during the normal registration process as they already exist in the coroporate ldap.
What i'd like to do is force them to login (simply so they don't register on behalf of somone else) and once they're logged in simply copy their data into the local ldap.
The problem is even if they are successfully authenticated by the corporate service, they don't (yet exist) as far as the weblogic server is concerned. is there a way to obtain the user id that comes with the authentication token ?
The authentication method is SAML 1.1
The application is a standard Java EE servlet based webapp using the struts2 framework.
Any ideas would be much appreciated.
Within WebLogic, you can define multiple authentication providers and set them up in the order you would like the system to use. Since you are copying data over, you would have to programmatically check for the existence of the account before attempting to create it on the LDAP server.
It would be a lot simpler if you use the external LDAP server directly instead of copying the data to the internal LDAP server, letting you attempt logging the user in and creating the account only while catching the appropriate exception.
When using Windows Identity Foundation (WIF) with multiple Security Token Services (STS), is it possible to provision users before they first access the application?
For example, let's say I have a web site called BufferOverrun where users can login and ask/answer questions and I want to support authentication with external Google accounts. When a user first accesses the page, they have to authenticate with their Google account, then they can access the web application. In this scenario, there are two STSes, Google (for identity authentication) and a custom one for my application (for authorization).
How can I assign claims to a user before that users accesses the system?
Since the identity is owned externally to my application, I cannot assign claims directly to that identity (and I wouldn't want to anyway, as they would be application specific). But since the user has not accessed the system, I do not have an internal identity to assign claims to. I see two possible solutions:
Wait for a user to access the system (creating some default application-specific claims), then use some internal provisioning tool to modify those claims as desired.
Have the provisioning tool allow users to manually map a default identity claim (email address, for example) before that identity authenticates by manually typing it in, so that on first access if the identity asserts that claim, a specific set of application claims are granted.
I see a few issues with both 1 and 2. For 1, all users have some implicit access to the system, even if the default application claims allow no functionality. This seems to work great for something like stackoverflow where the initial account has a certain permission set, and as the user uses the systems, new claims are granted. However, this is likely not desirable for all applications. 2 is error prone, as it requires an admin to manually specify a claim.
In both cases above, how do I provision the identity which has access to actually use the provisioning tool (i.e., an admin account)?
For this, I envision that during application installation time, I require a user to authenticate and set the applicaton claims for that identity to be such that they have "administrative" privileges. Is this a good implementation?
Historically (I am now referring to an existing application), the application specifically interfaced with Active Directory only. The way this was handled was that there was a built-in admin account (not affiliated with AD) that allowed the admin user to first login. After authenticating with the admin application, that user could search AD for users/groups and provision them individually. Any user/group not provisioned by the admin would not have access to the system at all. I don't see this paradigm being applicable to using an external STS like Google, etc, so I am trying to conceive an architecture that would enable external STS systems. Retaining the ability to search the STS is desired, though not required. In practice, the two STSes involved would likely both be Active Directory using federated services.
Note: This is similar to this question and this question.
When using Windows Identity Foundation (WIF) with multiple Security Token Services (STS), is it possible to provision users before they first access the application?
The answer is yes, if you have a way of identitfying those users (e.g. their e-mail)
In this scenario, there are two STSes, Google (for identity authentication) and a custom one for my application (for authorization).
This is frequently used, but not necessarilly always the case. If you rely just on Google, then you could simply have the authorization code in the app itself (e.g. "AuthorizationManager" classes, etc). The value of another STS is that it can be a broker for multiple identities (e.g. Google, LiveID, Yahoo!, whatever) and you can do some authorization related transformations.
Since the identity is owned externally to my application, I cannot assign claims directly to that identity (and I wouldn't want to anyway, as they would be application specific).
Why not? You can define a rule that says:
"Anyone authenticated with Google is a 'reader' in App BufferOverrun". You can even say:
"someone#gmail.com is a 'reader' on BufferOverrun", before someone accesses the app.
You can still use the original approach (an out of band admin account for setup). Or you can also "bootstrap" config during provisioning defining which is the claim that will identify admin users.
Take a look at sample "Federation with Multiple Partners and ACS" (sample 7) in http://claimsid.codeplex.com
We do exactly that.
I would like to create a user similar to admin, but with restricted privs. The user would be able to create/read/delete objects under a certain DN in the directory, but not others.
Typically, the native server providing the LDAP service has an ACL model.
Within that system, you can create users with appropriate trustee rights/ACLs.
For example, in eDirectory, you would grant this new user object BCRDI rights to the container of interest, then have your LDAP app authenticate as that user.
In Active Directory you can do the same thing.
In Open LDAP you can do the same thing.
The specific details depend on the server providing the LDAP service. (I like others, hate saying LDAP server, since really they are not LDAP servers. They are offering an LDAP service on top of whatever database they store objects in.)