I understand this is a really open question but I wondered what approaches you would all take.
Backstory:
Making a website that will have many different Roles that should have different access levels to the site.
Imagine a Role of Admin, Mod, Team Leader and Member. But there are say 3 teams with each of these roles within them. The Roles should only have permission level access to their own Team. all can access their own accounts and each others but only certain levels can change details as you go up. Admin is top level with full access, Mod can access say blogs and wikis, Team leader can manage the Team's details ect
What tools would you use to achieve this?
We are currently using AWS Amplify, Cognito and potentially AppSync.
Could i achieve this efficiently with IAM Groups or IAM Roles or AppSync?
Im new to all of this.
My initial thought was to grab the Cognito Group, Role and Tag Details when they login and store their TeamID and Tag/PositionID upon initial login and then do checks on the pages to compare the stores group and access levels and change the UI accordingly but is that the best way? Is there better free tools out there?
Thanks
Sam
Roles / groups are confusing.
Best explanation is you give roles to AWS services most of the time, and you assign real humans to a group.
If there is a dev or leader that has access to multiple different AWS projects, you can give them a role as well.
A majority of the time, roles are saved for Amazon services, like EC2 instances that need to access AWS services.
The majority of the time you put humans in groups. Unless the dev has an IAM account that is not under you. For example, if you are name#projectOne and projectOne is the root account, and someone else is name2#projectThree which is in a different part of your company. You could give them a role because their IAM account they are logging into is from a different root account.
Majority of the time, save roles for AWS instances like Ec2, etc. Just put IAM users in groups. If they are not under your root account, give them a role and then once they are in, they can get put in groups too, or can assign themselves into a group.
Don't give lower dev's roles, unless they are coming from a different dev team. If it is the same dev team (under the same root) just assign them to groups.
Continually check what permissions are being used by the devs in your group. Click on their name and then click on security advisor. If you see they aren't using a bunch of things (because it will show last day used...) then modify the group they are in, or create a new group for those specific activities and put them in that. AWS recommends giving the least access necessary.
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’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.
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.
I am currently working on a project where i have to make a Hotel Booking Application. There will be general user who will browse through available rooms and will have to login to book. Hotel owners will have account to manage their inventory. And there will be admin section to manage the app. I am confused about what is the best approach to scale this kind of app in Laravel. Because each kind of account will require different type of authentication. I have thought multitennent approach but doesn't seem like This app falls into this category. Thanks in Advance for any help.
For this scenario, you can implement Role based authentication.
You need to create 3 roles.
Hotel Owner
Application Administrtor
General user.
Based on the role, you need to provide access. If you haven't developed Authentication system, you can use Entrust along with Confide.
Entrust provides a flexible way to add Role-based Permissions to Laravel4.
Confide is an authentication solution for Laravel made to cut repetitive work involving the management of users.
I have a SalesForce.com account that I use for demos. In many cases, I need the users (anyone on the web) to be able to browse the tables without making any changes.
Is there a way to make the tables public or create a guest account?
You can add a new user and create a special permission set to only allow read access. Dev orgs come with two users, but you can deactivate/re-activate users to get around the limit. Or ask SFDC support to add a few more users to your dev org.
There are several places User log-in time and date are logged so you can track them.