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!
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 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.
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.
I have and AngularJS application that talks to WebAPI. Both login using Identity Server 3. I have an Admin role, but I want to expand on this so I can hide certain admin functionality in the front end from some admin users. So I need to check user permissions for admin users. What's the best way to do this? Do I just create a table in my database and assign permssions to users there? Or is there something in identity server I should do to assign permissions.
It's my understanding that application permissions would be tracked in your application specific database. In that database, you could track permissions by role (rather than user). Then, you could use the role claim(s) that come back in the token to look up the proper permissions. However, that's just one method...
This is a really great post on the subject written by Dominick Baier, one of the authors of Identity Server: Identity vs. Permissions
I'd like to know what the best way to keep the different users' database accesses under control is. Since I'm implementing the common scenario of making users login to the app before accessing certain pages, I thought that it would be also nice to restrict the database access to only the data each user needs to see by creating views and new users at database-level granted just certain permissions. Those database users will have the same usernames that those users have for accessing the app, and so, when users are loging in, I could access the database with the username they are providing on the application form... Is this the correct way to proceed?
Thanks!
Speaking of a web application, the common practice is rather to have a pool of connections with a unique user.
Each request uses an already open connection from this pool. This way you'll get much better performances. (connections already open, cache of the prepared statements, ...)
As for which data the users should have access to or not, this should be coded in the service layer of the application, not in the database (in the web-application culture, I would say).
Moreover, the system you describe will be a pain to maintain proper synchro between application users and database users.