I am working on an implementation in Salesforce for a customer which involves setting up partner module. We cannot setup access rights on User object standard fields based on profiles, and using partner login info, you can access all user info from Dataloader or Apex Explorer, which looks like a security hole in Salesforce.
Does anyone faced this issue before or has a workaround?
If I am understanding you correctly, your concern is that you can access all of the User records using the Login information provided by your customer.
I agree that this is a security issue, but I don't believe it is Salesforce specific as much as the security practices of your customer. If the user credentials won't need to access information via the data loader or Apex Explorer, then they should remove the "API Enabled" permission from the profile. If the credentials should only have API Access they should turn on the "API Only User" permission on the profile.
What it comes down to is they need to restrict the "un-trusted" users to only the permissions and access levels that they need. I have found the profile permissions to be capable of meeting all of my security needs.
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.
We used to be able to have social accounts request access packages by signing in at myaccess.microsoft.com. Now, we get an error that says you can not sign in with a personal account. Why is this the case since it remains possible to create a domain like gmail.com or outlook.com as a connected organization in Entitlement Management?
Also, after landing on the myaccess portal and expanding an access package that a user has been approved for to view its resources, it used to be able for example, to open a SharePoint site or an application directly from this view by simply clicking on the resource or clicking an open Now that ability has been removing leaving us to have to send links tot he resource to users. This degrades experience substantially. Can we have this ability returned?
Please check the type of personal account in your portal, and if guest, you cannot log in myaccess.onmicrosoft.com , if created in the portal or of type member, it is accessible.
This is the relevant doc.
Sign in to the My Access portal.
Be sure you use your organizational (work or school) account. If
you're unsure, check with your project or business manager.
I invited my personal account (user type) to test if I login directly myaccess.onmicrosoft.com.And the following screenshots do report errors.
We are looking to set up a solution to monitor primarily the Global Admin role in Azure AD, so if a user is added to or removed from the role an e-mail is sent to a specific mailbox.
On our local AD we have a working solution for this, but I can't seem to find a similar solution for AAD.
In the Office 365 Security & Compliance Center > Alerts > Alert Policies there is a policy called "Elevation of Exchange admin privilege" which basically does what I want, except it only targets the Exchange Admin role.
I've tried creating a new policy from scratch, but as far as I can tell there is no way to choose to target a specific role. There is only the "Granted Exchange admin permission" and nothing really comes up when I search for "role" or "admin" in the "Activity is" drop down.
I've also looked at the MCAS (MS Cloud App Security) policies but nothing there seems to be what I need either.
I found this article: Monitor Office 365 admin role changes in all customer tenants but it seems to be geared more towards multitenant environments and requires quite a bit och additional setup. I was hoping there was a simpler solution for a single tenant environment.
Kind regards
If you have MCAS, I think it's possible that you have PIM as well (privileged identity Management. it requires aad P2 skus. But assuming you do, then it's very simple to do this. You would just go into the PIM in azure, click azure ad roles, click manage roles, choose the global admin role, Click role settings, and you will see options like this
If you don't have PIM, then it becomes quite a bit more complicated but could probably be less complicated than your example, you could set up log analytics to ingest azure ad data, and using a query pull out that information (role assignment event for example), then you could set up an alert in monitor referencing a log analytics workspace. https://learn.microsoft.com/en-us/azure/active-directory/reports-monitoring/howto-analyze-activity-logs-log-analytics
I’ve been asked by a customer to find a way to collect all permissions for all app registrations in the customer’s AzureAD tenant. The customer has 1500+ App Registrations, so checking each manually isn’t an option. Most of these are redundant but the customer wants to review all of them to look for Graph API permissions that they’ve deemed sensitive. The problem is, there isn’t a way to export this info in the portal and Get-AzADApplication doesn’t give me actual permissions, just friendly descriptions of them. The customer would like the ACTUAL Graph API, such as Mail.Read.
I’ve attempted to script this with the assistance of a few more senior PFEs, but we’ve been unable to make any progress passing various properties between Get-AzAdApplication, Get-AzADServicePrincipal and Get-AzureADOAuth2PermissionGrant. We reached the point where we were able to get the Graph API permissions from the Service Principals, but the resultant permissions were in an unusable format.
If anyone has any suggestions on how to get this information into a concise format with (preferably) the Graph API permissions as mentioned above, I’d greatly appreciate it. I’d rather not go back to the customer and say it isn’t possible, as this is a new customer and I’d rather not say ‘No’ to my first task. 😊
Use Microsoft Cloud App Security for that purpose. This is tool designed, beside other features, especially for that purpose.
You open https://security.microsoft.com/ as a Global or Security Administrator, then you have quick overview on central place:
This will bring you to the MCAS portal, where you have solicit view on all applications with a rating, according to Microsoft standards for "Highly priviledged" access:
A direct view to applications, which users are using these applications, what permissions are granted. It even has filtering capabilities allowing you filter apps based on access level sevirity or even some Graph permissions - like Access e-mail on behalf of the user.
Your customer should really be using the Microsoft Security Center and monitor their security score: https://learn.microsoft.com/en-us/microsoft-365/security/mtp/overview-security-center
Then looking at MCAS: https://www.microsoft.com/en-us/microsoft-365/enterprise-mobility-security/cloud-app-security
You can use this script to list all delegated permissions and application permissions in Azure AD.
The key of the script is Get-AzureADServicePrincipalOAuth2PermissionGrant -ObjectId.
Based on my test, the permissions in the result is in this format: email offline_access openid profile User.Read.
I think it's what you need.
My organization is taking a look at the security of registered applications within Azure Active Directory (AAD) and have concerns around the ability of individuals to add client secrets and certificates for applications that are using the "application permissions" model. I'm working to help narrow the roles of individuals within the organization to restrict this, but this investigation begged the question of what a malicious insider could do if he or she could add a client secret to this application.
I've looked through the 30 Days of Microsoft Graph blog series, which is excellent, but wanted to clarify what else can be done to prevent an insider from gaining access to the permissions this application would allow.
Does the redirect URL itself protect against this kind of scenario, provided the organization retains control of all registered URLs (meaning, for example, that https://localhost isn't registered)? Based on this post under Step 3, I assume the answer is yes but wanted to make sure this is the case.
Is it technically correct to say that without the redirect URL being secured/owned by the organization, a malicious insider who could add client secrets could exploit the permissions granted by the application?
If you are able to add a client secret to an app that already has been granted application permissions to something, then this user can use the new secret to get tokens and access those resources as the app.
Redirect URL is not used with application permissions, only delegated permissions.
This is because there are no redirects in the client credentials grant flow, which is used when acquiring a token with app permissions.
It's just an HTTP request.
So you are correct in your assumption that being able to add a new secret to an app that already has permissions can be a security issue.
There are audit logs though, and I believe adding a secret/certificate is logged.