I'm building an app using which the users registered(from the IAM page) for the project can access the resources of that project. I need the authentication when the URL is hit. Is there a way to achieve this?
Is it possible to provide IAM roles specific for a user request (assuming that the user will login using his email id) to access the resources based on IAM level permissions?
In the early days of AppEngine it was pretty easy to do some basic auth/access-control, but lately they're moving it to something called IAP.
From your wording I am assuming you are trying to abstract administrative tasks of a GCP project to lesser privileged administrators.
Questions 1 and 2 can be quickly solved by defining privileges in IAM using a pre-built roles or creating a custom role if you need to be more specific. Hereby you can use GSuite, GMail, Google Group accounts and let them sign into console.cloud.google.com. They will consequently only be able to see and act upon what you've assigned to them to in IAM.
If you still want to go through with building it yourself, every product does provide an API including authentication. Best practice for your use case is to instead of assigning an individual user access to a resource, you rather create a service account and then allow the user to call that service account. For this GCP has the Service Account Actor Role described well in the official documentation and also Salmaan Rashid provides a good practical insight on medium.
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 looking to fetch lastSignInTime for all users by using the UID of the users.
I am using react.js
I have attached a screenshot of it so that you will have an idea of what I am looking for.
Hope, you guys help me out with this.
There is no way to access profile information about other users than yourself from within the client-side SDKs of Firebase Authentication.
If you need such information in your app, the two main options are:
Write the information to a cloud-based database (such as Firebase's own Realtime Database or Firestore) when they sign in, and read it from there.
Use the Admin SDK to access this information for all users in a trusted environment, such as a server you control or Cloud Functions. From there you can then expose the information to your ReactJS application as a custom API.,
In both cases, be sure to take care of securing access to the information, by limiting the amount of data you expose and who can access it.
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.
I am trying to create a React app where a user with "admin" role can create a new user in firebase.
The workflow would look like that:
normal login -> check userRole -> if admin: show createUserForm.
As far as I have read from the documentation, I would need an Admin SDK, but the problem is - how to implement it on client-side app? Has anyone gone through this process?
The Firebase Admin SDK should only be used in a trusted environment, i.e. a server you control or Cloud Functions. It should not (and cannot) be used in a client-side React app.
If you want to allow certain users of your React app to create accounts for other users, you'll want to move that part of the flow to a trusted environment where you can use the Admin SDK.
So the flow becomes:
Detect in the client-code whether the user is an admin (likely using a custom claim) and only show the form if they are.
Call a Cloud Function from your client with the input from the form.
Ensure the user calling Cloud Functions is authorized.
Create the user account in the Cloud Function using the Admin SDK.
As you can see this is quite involved. I highly recommend considering alternative use-cases, such as what it actually is that you want the admin to control. Once you enable a provider in Firebase Authentication, any user can create an account with that provider. Trying to control that from within your application code is just a recipe for problems. Often what you're actually trying to control is what a specific user account can do: e.g. only approved users can access certain data. Depending on where you store this data, that is much easier to control. For example: if you store the data in the Firebase Database, is is common to create a whitelist of approved users in such a case (or the inverse: a blacklist of banned users).
I'm building a service where each user has a calendar, I want to sync users 365 calendar events into their calendar, the tricky part seems to be, that this should be done repeatable by background job on the server, to keep them in sync.
I feel like I've read a bible of documentation from Microsoft, but still gotten nowhere. I eventually stumbled upon this article https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oauth-client-creds which allows a server to query the graph api, on behalf of users. This is exactly what I want.
Having created a Azure account, and Active Directory service, I found that only users within the tenant can use this, which makes it rather useless, requiring to add users manually from azure panel.
AADSTS50020: User account 'm#****.com' from identity provider 'live.com' does not exist in tenant 'Default Directory' and cannot access the application 'c0193dea-5145-430a-9c90-325f1229a1fc' in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account.
So I'm back at square one, how can I achieve what I described?
I'm not looking for a code implementation, merely a description of how to navigate the monstrosity of Microsoft.
Thank you
Update: Accordingly to Marc link. I tried to flick the multi tenant option, and change the endpoint to use common instead of tenant id. Sadly i'm still getting the same error.
You cannot sign-in to AAD with a non-AAD account using the v1 Endpoint. If you want to use a consumer Microsoft Account (#outlook.com, #hotmail.com, #live.com) then you need to use the Converged Auth model provided by the v2 Endpoint.
I have a walkthrough for the v2 Endpoint that you might find helpful: Microsoft v2 Endpoint Primer. It is similar to the v1 Endpoint but you'll need to register via https://apps.dev.microsoft.com rather than the Azure Portal. Also, v2 apps use Scopes instead of Resources and are multi-tenant out of the box.
This is a broad a question for Stack Overflow. That said, you're incorrect about Azure AD. It is absolutely not limited to a single-tenant. You do however need to register it as a multi-tenant application:
How to sign in any Azure Active Directory (AD) user using the multi-tenant application pattern