I'm really at a loss here, and I cannot seem to find any information at all regarding this...
I'm putting together a membership management app for my coach's jiu jitsu gym using Unity and Firebase. Gym members can check in using the app and keep track of class schedules.
I want the admins, such as my coach (the gym owner) to be able to change values of the members information, such as if a membership fee isn't paid or if a liability waiver has expired. This way the member can see on their app if they are paid in full.
I cannot, for the life of me, find any instructions as to how to achieve this, nor can I seem to simply override it in the Firebase console. Is there any method for allowing an admin user to write to other user accounts?
What you're looking for is some form of Access Control.
Option 1
As #ltapox points out: maintain a list of users with elevated rights in RTDB. You can query against those values in your Security Rules.
Option 2
Set Custom Claims in Firebase Auth. This has to be done on the server, and basically adds custom properties to the Firebase Auth object of a user. You then have access to these properties in your Security Rules (see docs here) and on the client (docs).
Of the two options, I would recommend option 2 even so it's more effort. The benefit on the client is you know what type a user is by just looking at their Auth object, without querying RTDB.
Related
We have an application (C# on the server, using AngularJS / Web Apis for a single page application) that assigns users different roles, which are stored in the database. When the user logs in, the user object (including RoleID's and RoleName) is transformed into a JWT and sent to the user, which is then used as authentication.
We're having trouble determining the best way to maintain and use these access roles however. Specifically, to use them in the current set up, it would seem that we have to hard code either the name of the role or the ID into the application.
For example, on the client side, if we want only users with a Manager role to be able to see and click a button, we would have to explicitly state that, ie if (UserService.HasRole('Manager')) { doStuff(); }.
Conversely, we'd have to do the same thing on the server side (because everyone knows relying on client-side security is bad). When the server gets a request on the API, it checks the JWT for validity and, if valid, checks the User's roll to see if they are allowed access to the specific web API endpoint.
This all seems prone to breaking if a role is renamed, or the ID changes. I generally hate hardcoding things like this. Is there a better methodology or approach that can be taken here?
In the past, when we've done RBAC (Role Based Access Control), we decouple the Role from the Permission e.g.
Role Permission
===============================
Manager Create Order
Manager Delete Order
Till Operative Create Order
Administrator Create User
Administrator Suspend User
etc.
This could be stored in a database and cached in something like Redis. Two tables, Role and Permission, where the Permissions need to match the ones built into the application (you could script this).
So your permissions grow with your application e.g. you add a new dining service, you can add a "seat diners" permission. The permissions for existing/mature bits of the software should rarely change (unless they were written incorrectly), whereas the roles are entirely fluid and can be renamed etc.
You can then use an annotation/security framework to ensure that the user making each API call on the server side has the correct role required.
You can even make it additive and allow a user to occupy multiple roles at once to blend things together.
You may maintain your user to role mapping in the database also in another table (using FK constraints) or you may use something like LDAP with the mapping being looked up from the DB/cache.
On the server side, Microsoft has built in management for roles. I would first look at
http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity
And then I'd also look at the the IdentityServer project for working with JSON Tokens on the server side.
https://brockallen.com/2013/04/14/getting-json-web-tokens-jwts-from-adfs-via-thinktecture-identityservers-adfs-integration/
On the client, I would suggest storing the tokens as either just in memory javascript or if you want them to persist, I would store them as cookies but make sure to set the cookies to not be accessible by JavaScript by using the httponly parameter when creating the cookie.
HTH's
Typical case of making a simple application, boss likes it, sysadmin wants to be able to configure it.
I made a simple login helper application to assist my team members with logging into a pile of different websites/tools in the morning. You create a list of sites, enter your most used password, it logs you in (and prompts for a password for sites with a unique one). Gif here: http://i.imgur.com/0HIVbMw.gif
The sysadmin at my facility has requested that I store the list of websites in the registry and make it available for management via Group Policy (So that the list can be pushed to everyone, and limited in some way). I'm going to be honest, I know nothing about Group Policy. I have heard that storing data in teh registry is not always the best option.
How can I make my applications setting and/or data configurable through Group Policy? Do I need to store it all in the registry? What options do I have that can give our sysadmin the control he desires?
Edit: Can a config file be pushed to the profiles of all users that the application can use?
I've found a lot of information about this subject; however, not much in the way of how to implement my specific scenario. Unfortunately, my company's AD is half-pregnant, so to speak. The users are there, but that's about it.
I'm creating an intranet and obviously need to authenticate users which I'll use Windows Authentication to do so. However, since my AD does not contain any of the additional information typically used in an intranet (heirarchy of users, meaning managers and departments associated with each employee, etc.), I wanted to use Identity to satisfy that need. And although we do utilize AD Groups, it's painfully difficult to get that setup and want to use Identity for role based authorization instead of AD.
Although fairly new to Identity, it's easy enough to figure out, and Windows Auth is easy to implement.
What I'm missing is the know-how to marry the two together.
So my scenario is - Authenticate the users with Windows Authentication. Once authenticated, switch over to Identity for role-based authorization (claims?) and any other meta-data (such as user information or application specific data)
I've seen this question asked, but not sure if it really is that simple or is there more to it. And I'm not sure if it really fits my scenario. And this question seems to be exactly what I'm asking, but no responses. Finally, this question seems even closer to what I'm asking, albeit using the Membership Provider. I'm guessing this may be the way with Identity as well?
So, in my instance, I'm using Windows Authentication and so I will not have a login form or action (strict requirement to NOT have users enter username/password - it should be seemless). In the case of an employee going to the intranet for the first time, they authenticate with AD, but then how would I save that user to the Identity store? Would it make sense to send new users (employees that have never been to the intranet before) to a Register page after they've been authenticated through AD to ensure there's an associated record in Identity? I could then, as part of the registration process, have them select their department and manager. After they register, a human-based validation process would have to happen to ensure the user selected the correct department and manager, but that's the least of my worries right now.
Recommendations, links, or just some simple guidance would be appreciated. Thank You!
The Problem
I'm an ASP.NET newb who has been given the task of creating a multi-user password management system for use within a secure intranet. Essentially the user will be automatically logged in via windows authentication, which will then provide them with an appropriate view depending on their group. For example, a user of group 'admin' would be able to access all password entries, and a user of group developers would be able to access all password entries belonging to users in the 'Developers' active directory group. Users should be able to create, update, and hide (delete) password entries.
What I have so far
So far I have essentially been figuring out what will and will not be impossible, and researching technologies. Windows authentication itself appears to be easy, however it breaks when I enable the role provider, which appears to be necessary for providing different views for users. By 'breaks' I mean specific users are still recognized, but entire groups are not.
The different views must be automatically served, and I have come up with two techniques to do this:
Checking the role (group) on the home controller, and serving the appropriate view. This would require a long list of messy 'if' statements, however.
Serve a common view and allow or disallow viewing certain elements according to group. This would require putting a lot of logic in a view, which is as I understand inappropriate.
There will be a password.cs model class which will hold all information on a password entry including which groups should have access to it. I cant really think of any other necessary models, as the user information would not need to be stored.
Security concerns
I understand that storing such sensitive data in a single location could be a recipe for disaster. Passwords will be appropriately encrypted using pre-exising libraries which I have access too. I will have help with this area. Also, passwords will not be view-able as plain text on the system to avoid shoulder-surfing, but will be displayed as asterisks and will be copy-able to the users clipboard.
My questions
Essentially I would like some advice on how to structure the system and the most simple ways to enable active directory authorization with windows authentication. I would like some advice on how to provide the appropriate view for the user, and how the different areas should fit together. I am not expressly asking for any help with the password security side of things, but any insight or discussion would be warmly welcomed. Essentially, I would very much appreciate any help, links to tutorials, or suggested readings.
My tools
At my disposal I have Visual studio professional 2010, MVC 4.0 and .NET framework 4.0, and standard (non-admin) access to the server.
I will be able to give experimental code which I currently have in place tomorrow (It's 22:30 GMT, I'll be back in the office tomorrow morning). Let me know if you need any more information.
I have implemented two solutions where I had to integrate MVC with Active X Directory. There are multiple solutions (e.g. Security Application Block from Enterprise Library). However, I ended up using AzMan and the RoleManagerAzManProvider. I ended up with this combination because I did not need to deploy any additional libraries.
I started with this article: [http://msdn.microsoft.com/en-us/library/ff649313.aspx][1]
Even though it is written for ASP.NET, I was able to use it for MVC. I placed my XML Local Policy Store underneath app_data and configured the web config
<add name="LocalPolicyStore" connectionString="msxml://~/app_data/MyPolicyStore.xml" />
This worked out nicely for me because the Policy Store allowed me to define Application Roles and, when deployed at my client, map those roles to AD Accounts.
After that, I implemented a custom Authorize Attribute that I registered in the Global filters. This is where I made the decision which page the user would be redirected when they logged into the app. Finally, I used the standard Authorize Attribute on controllers based on group names.
I have thought about writing a set of Custom Editor Templates and Display Templates that would take roles into account so that I can render different UI for controls based on the User's application role (render a span instead of input).
Although your application is probably already written, I hope this helps.
Chuck
I want to implement roles and permissions on a web app we have created and I am looking at using System.Web.Security.SqlRoleProvider to implement this.
My problem is that each client will want to be able to configure who can and cannot perform actions in the system and no two clients will want the same, so creating basic
Admin, User, Manager roles to cover all won't suffice.
What I am proposing to do for each screen is create roles as follows
Screen1Create, Screen1Update, Screen1Delete, Screen1Read
Screen2Create, Screen2Update, Screen2Delete, Screen2Read
and so on.
I would then allow the client to select the roles per user, which would be stored in a cookie when the user logs in.
I could then read the cookie and use user.isinrole to check if each method can be called by the current user.
I realise there is a size constraint with cookies that I need to be aware of. Apart form that, does this sound feasable, is there as better way to do it?
Many thanks for any input.
Really if you want to program this all yourself to the cookie level you're risking opening security holes. The way to do this is with forms authentication combined with role based authorization. Asp.net will give the user a tamperproof cookie.
If you implement roles you can then easily mark methods:
[PrincipalPermission(SecurityAction.Demand, Role="Screen1Create")]
or use code to see if someone is in a particular role.
Lots of info:
http://weblogs.asp.net/scottgu/archive/2006/02/24/ASP.NET-2.0-Membership_2C00_-Roles_2C00_-Forms-Authentication_2C00_-and-Security-Resources-.aspx
Remember that cookies are user-supplied inputs, so if you're going to store the privileges of users in cookies, you must use a keyed hash function (such as HMAC-SHA256) to make sure that users do not grant themselves additional permissions.
Or, if you store all the permissions in your database, it'll be persistent across client computers and you won't need to validate its integrity every time you wish to use it.