Need some help trying to figure out my authentication options for using the embedded service in an app owns data scenario.
Is the only way to authenticate and generate tokens by using your Azure AD credentials? I have went through the examples and got everything running just fine but....
Here at the university that I work at our credentials change every quarter. This means all 10 or so apps where I need embedded reports will have down time as I update this information every quarter. This is going to create a lot of work. Not only that but I really don't like the idea of the rest of the developers on the team managing the code having access to my personal AD account which is tied to lots of other personal university resources..payroll.. etc..
Am I missing something is there not another way to go about setting this up?
Is there anyway to setup a separate membership provider to authenticate against?
Thanks for your help.
Perhaps a service principal is a better approach for you. Instead of using a service account with a username and password you use a secure API KEY instead.
See below link, there are some limitations using a service principal as apposed to a master account:
https://learn.microsoft.com/en-us/power-bi/developer/embed-service-principal#service-principal-vs-master-account
But no, your not missing anything you if you want to use app owns the data model with a master account you'll have to know the username and password and ideally that should be a limited account that only has the access it needs, is not on the same password policy as normal user accounts where its password can expire etc.
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'm trying to configure Azure B2C in such a way that it prompts the user for a login id and password, these are then authenticated using an external REST call, and it returns an OIDC token containing whatever claims I wish to return in the REST call.
I can make the REST call work and add claims to an existing example policy no problem. The problem is removing the superfluous Azure AD behaviour without breaking the policy.
If the user doesn't exist in the Azure AD Directory, I don't care, I'm not interested in the user having an Azure profile at all, I want all the user data to come from the application's own database, but I haven't found a way to stop Azure from redirecting the user to create a new local AD account if one doesn't already exist.
The documentation is very dense and has a few walk-throughs of how to do a few of the things it expects you to want to do, but nothing like what I want to do. It points to a startup pack and some samples, but again these are very fully featured and not what I want to do, and trying to work backwards from them is proving intractible.
What's lacking is something that describes how to create a custom policy from scratch and take full control of the process of authenticating the user.
Does anyone have any suggestions of how to go about this, or know of some good documentation about this kind of thing?
There's an example here.
Basically, self-asserted screen to get credentials, verify against API, send JWT to application.
I'm creating the user authentication in a web application, and I want to use Identity Server for resource protection.
The sample code and documentation shows how the user logs into Identity Server after creating an account for it. That is to say, they log in with their own Identity Server account. The quickstart even provides a UI.
But I don't want users of my application to have to log in to Identity Server, an external website. I want them to only have to log in to the web application.
So how to proceed? It just doesn't seem at all clear from the documentation how you're supposed to handle this scenario, which I would have thought would be the most common.
Do I just use a pre-defined API scope and user for token validation, holding for all the website's users? That doesn't seem to be very secure given that any user of the website or anyone with the client name and secret would have a valid token. Not sure what the point is in having the security if it's that easily worked around.
Or do I interact with my Identity Server instance somehow after the user is registered in the web application, and store the new user in a database? I can't find any mention of this in the documentation . It all seems to be very muddled to be honest.
Please could anybody shed light on some of this? What is the "standard" approach here? To have the user sign in to the external Identity Server website? That seems a great way to annoy your users.
If you only have one application and you don't intend to add more applications that needs to share users, then you should look at ASP.NET Core Identity
The whole point with OpenID-Connect/IdentityServer is to delegate the managing and handling of users/passwords (authentication) to a central entity. So individual applications don't need to deal with that complexity. IdentityServer is useful when you have multiple applications or if you have more complex integration needs. It is also perfect if you need to customize it to your own needs. If you don't need the customization part you can also outsource it to someone else like Auth0 that give you an IdentityServer like experience as a service.
I have a Xamarin app that uses Easy Table and uses "Allow anonymous access", this means anybody can access my Easy Table as long as they have the URL. So to increase the security of my app, I would like to allow only my Xamarin app to access the Easy Table I created.
Can this be done by changing the Easy Table option from "Allow anonymous access" to "Authenticated"? And if this is the case should I create an account in Active Directory/Facebook/Google and have the username/password embedded in my Xamarin app such that it can authenticate first before accessing the Easy Table?
Note, I have my own user authentication based on user email address and password and it is working okay, but this is on an application level authentication only(i.e., if users provides correct email address and password, they are able to order, view history, etc.). This obviously will not prevent other apps in accessing my Easy Tables as this authentication uses the Easy Tables in the first place.
Thanks everyone!
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.