I'm developing an ASP.NET MVC application. I need to support multiple authentication mechanisms (this app is used by multiple customers, each with their own preferred authn provider). One auth provider will be Active Directory. The AD integration for authentication is straightforward and I have no problems with that.
For authorization, roles will be stored in a local database (NOTE: we cannot use Active Directory groups for doing authorization - roles need to be local application roles because we support multiple authn providers and AD admins won't want to create custom groups in AD just for our app). My expectation is that we will need to create "stub" user accounts in our local database in order to do the User-is-assigned-which-Roles mapping. These stub user accounts will also be used to indicate which users are authorized to access the application (not everyone in the AD database should have access).
The anticipated flow of control will be:
User accesses login page > enters credentials > posts credentials to app server.
The app validates the credentials against AD. At this point, we know if the user is authenticated.
The app checks the user's SID to see if a "stub" user account with that SID exists in the local database. If not, the app displays an "not authorized" error message to the user.
The app will look up roles for the user in the local database user-is-assigned-which-roles table.
User identity info including roles will be stored as claims and the app will use typical claims based authorization (i.e. ClaimsAuthorizationManager).
My question is what is the best way to create "stub" user accounts into my local database? My guess is that we should use some sort of AD export script to export AD accounts for those users that should be granted access to the ASP.NET app and then import those users into the local database (NOTE: I expect that the stub account will contain minimal info - perhaps just the user's SID from AD and maybe the username).
A batch export/import is probably OK as an initial deployment process. After the app is up-and-running and new users join the organization, I expect a more user-friendly mechanism will be desired for granting a new user access to our app (other than exporting/importing the new user's account from AD to our local database). My guess is that we'll need some sort of user browser screen so that an admin in our app can browse the AD directory, select a user, click a button and then have that user's "stub" account created automatically in our app.
Has anyone implemented an application with similar requirements? If so, how did you bootstrap the creation of "stub" accounts in your local database? Is there a better way to address these requirements?
Please feel free if this can Help You Custom Annotation Authorization
It's only a workaround, or just an idea, not a solution...
To use it you only need to use Annotation in the controller
e.g.
[ARQAuthorize]
public class BlaBlaController : Controller .....
I am currently implementing a similar solution. Here is how the application works. I'm using ASP.NET MVC 5, ASP.NET Identity 2.2.1.
I am using the Identity framework to manage users and roles within the application. The user goes to a login page, enters their credentials. The application checks against the application DB to see if the user exists. If not it throws an error that the user doesn't exist in the database. If the user exists, it authenticates against AD. If authentication fails they get an error message, if it doesn't fail I create a ClaimIdentity from the user out of the database (not the user in AD) and pass that to my SignIn method.
My user in the application DB has the same username as the AD username and I use that as my stub. I also include the domain of the user in the DB as well in the case that I might have multiple domains I need to support. With Identity, don't forget to also populate the SecurityStamp field with a guid.
The plan is to bulk import the users and permissions from a spreadsheet and I have some standard CRUD actions created to allow creation of individual users and assigning of roles after that.
Related
I am building a booking system and I am using firebase as the backend. The system has two parts:
the customer end which is an app.
the business end which is a website.
I am using the same firestore database for both and also using the same Firebase Authentication project.
So I need two sets of authentication sets one for the customer end and another for the business end.
I have added two apps in a firebase project for sharing the database. My issue is the users shouldn't be able to sign in at the business web app with their credentials and vise versa.
How can I create two sets of authentication details one for each app?
Authenticating a user with Firebase does not determine whether the user has access to anything app-specific. Authentication is merely a method where the user proves who they are.
You then use this information about the user to determine what they can do in your app(s), a process that is known as authorization. Authentication and authorization go hand in hand, but are still separate steps. And Firebase Authentication only takes care of the authentication part. Authorization is up to your app.
The typical approach to your scenario is to actually have only one set of credentials for each user. If the same user needs access to both the app, and the web site, they can sign in with the same credentials. Based on your knowledge of the user, you then grant or deny them access.
Most apps have a users collection with a user profile document for each user (using their UID as the key). Then after the user is authenticated your app could read the user's profile document and read for example two fields named isCustomer and isBusiness, to determine if the user has access to the app/site. You'd also use those fields in the security rules of your database to grant/deny access.
An alternative is to give each user profile in Firebase Authentication a custom claim to determine whether they are a customer and/or a business. In that case you'd need server-side code to set the custom isCustomer and/or isBusiness claims and use this in your code (and database) to grant or deny access.
Also see:
How to create firebase admin user for authentication in java
How to use the same Firebase Auth for Two different Flutter apps?
role based authorization and role based access control flutter
So I'm trying to create custom roles in Azure AD for an Asp.net mvc5 web app. I did a lot of reading up, but basically it fails due to lack of auth. I issue the PowerShell command New-AzureRmRoleDefinition -InputFile myNewRole.json but it fails saying that my (current logged on user) does not have authorization to perform action 'Microsoft.Authorization/roleDefinition/write" over scope...
Well, the error message is clear. At the same time, if I list my user's roles I am 'owner'. What privileges is needed to create custom roles in Azure AD if owner doesn't suffice?
Hi in your assignable scopes section can you confirm that there aren't any typos and the scope is your subscription GUID. We have come across this scenario where there was something awry with the scopes section.
I used AWS Cognito to authenticate users in my iOS application. The users of the app will have to enter the email, phone number and their name in order to register and Amazon will be sending a SMS to authenticate the phone number.
All of these are working fine. I have few questions and they are :
1.) I want to know where these data are getting saved ? It's not there in the Dynamo DB (However, I found the list of users in AWS Cognito --> Federated Identities --> Users , but not in a Table inDynamoDB)
2.) Now, once the users are authenticated, I am allowing the users to interact with the application. The first task will be that the users will have to complete their profile. I want to know if in case if an user is NOT authenticated will he be able to complete his profile ? Ideally, he should not be allowed. But is this happening automatically ?
EDIT
1) You are correct, data is not stored inside dynamo for user profiles. Cognito has an internal data store in which user data is persisted. This can be viewed and edited (as an admin) through the 'Users' tab of your user pool.
2) They should not be able to, and it is not happening automatically. The only way to update attributes stored against a user is as an admin (which the user shouldn't be able to do) or with the token that they get from signing in, so what you're aiming for is very do-able.
I am currently using firebase to make an ionic app. I am using firebase simple login for social auth (facebook, twitter, email & password). The auth works perfectly, it $broadcasts the authed user. However it doesn't seem to create a user in the actual firebase db. I was wondering how I can get the users that have been authed using my app.
For most of the authentication protocols it supports, Firebase doesn't store user data anywhere. Even for the protocols where it does store data (I only know of email+password doing this), it stores this information in a place that your application can't access (though you can find those users in the dashboard of your Firebase).
To quote the Firebase documentation:
It does not store profile or user state in your Firebase. To persist user data you must save it to your Firebase.
What most applications end up doing, is keeping a list of users inside their Firebase that they manage themselves. So when a user first authenticates with the application, it creates a node under /users/<uid> that contains the information for that user.
See this section of the Firebase documentation that describes storing user data.
Firebase does not store profile or user state in your Firebase instance. To persist user data you must save it to your Firebase.
Firebase provides multiple authentications services
Using existing social login providers such Facebook, Twitter, Google, and GitHub. Using these services provides an option for your users to access your application without creating a new account.
Using built-in support for logging in with email & password. This requires registration and account creation that is handled by Firebase. The user account information is stored outside you application.
Using a custom authentication to implement existing server-side authentication, single sign-on, legacy systems, or third-party OAuth based services (such as Yahoo).
Once authenticated, Firebase return a variable auth to your application that you can use for authorization and access control. This variable is null for unauthenticated users, but for authenticated users it is an object containing the user's unique (auth.uid) and potentially other data about the user.
If you want to persist additional user information such as name
and location, then you need to use auth.uid and store it in your
Firebase with additional profile data.
Internally, Firebase generates JSON Web Tokens (JWTs) and creates authenticated sessions by calling Firebase.loginWithCustomToken() with those tokens. Each user is assigned a uid (a unique ID), which is guaranteed to be distinct across all providers, and to never change for a specific authenticated user.
The user data for firebase authentication is stored in firebaseLocalStorageDb in IndexedDB. After login to website, if you delete firebaseLocalStorageDb, the login user data for firebase authentication is all deleted so you need to log in website again.
I am trying to learn ASP.net MVC -
I have successfully implemented the basic authentication and authorisation.
My application is multi tenant (One DB one Schema) and multi Users.
Each user can be added to any tenant by admin.
A user will be given a list of tenants he can use upon logging in.
Then the user clicks on one tenant and enter in to the tenant's application data and can update, create etc. (invoices for example).
I am using cookie authentication, should I be adding each tenant the user is authorized to use as a claim or check on server side for authorisation when user switch between tenants.
Using cookie claim will save DB queries if I have tenant list for user as claim. But Cookie has 4k limit what if a user can access thousands of tenants such as admin.
You can save user-tanent relation in a table , and put row id in cookie , so you can check that row when user logged in.