I'm looking for some guidance and have had a hard time finding a straight answer via Google.
I am building a web app using Google Cloud Platform and Firebase and would like to grant users access to only their own subdomain. So for example, if user 1 is part of the organization Lakers, I would like the domain they use to be lakers.myapp.com. If user 2 is part of Bucks, their app would be hosted at bucks.myapp.com. When somebody who is not authorized visits one of these domains, they should not be able to view anything since they are not authorized under that subdomain (just like any normal web app). I have the login all set up and can redirect the user to their subdomain, but what is the process of checking that the user is authorized to view that subdomain?
If the answer has many parts, I would be happy to receive some links to resources on how to do this; I wanna be sure it's done right.
For the first part: (Can we restrict users ( Identity ) based on the GCP domains ?) , then answer is yes. The Resource Manager provides a domain restriction constraint that can be used in organization policies to limit resource sharing based on domain. This constraint allows you to restrict the set of identities that are allowed to be used in Identity and Access Management policies.
Organization policies can use this constraint to limit resource sharing to a specified set of one or more Google Workspace domains, and exceptions can be granted on a per-folder or per-project basis. For more information about adding exceptions, see Override the organization policy for a project.
For the second part:(How do I lock down Firebase Database to any user from a specific email domain ?). If you're using the new Firebase this is now possible, since the email is available in the security rules.
In the security rules you can access both the email address and whether it is verified, which makes some great use-cases possible. With these rules for example only an authenticated, verified gmail user can write their profile, please see the Stackoverflow Link for more details.
Related
Maybe I wasn't searching the documentation properly, but what is the recommended standard way of treating authorisation levels/classification for admin users in firebase?
Let's say in classic admin user scenario, where admin should have the access to all user accounts while normal authenticated users have write access to only specific objects.
I came accross this post but the solution using firebase secret is not good enough in this case. Firebase secret is meant to be used by server and setting up the extra server authenticating admin users and talking to firebase is certainly the option, but the complexity and programming overhead is increased.
The better option is using the security rules. Question here is - Does not this generate an extra overhead for each single read/write operation? The number of general users could be in millions while there is only handful of admins. Secondly you do not want non admin to be authenticated by management tool even though they will not be authorised to do anything.
Third option - however I don't know how would I achieve this - limit authentication to admin interface webapp only to specific admin users or set the limit for the specific domain. Let's say only {name}#myappadmin.com will be allowed to be authenticated thus I will not need to do the authorisation check before each operation. Is this even possible using only Firebase as backend?
I just don't still get Claim Based Authentication/Authorization workflow.
The application allows authentication via Facebook.com
After the user is authenticated, an admin can give her/him a claim of having the role of Manager, which creates another claim (where?)
Of course, this claim won't be on the facebook.com server, question 1: where should that claim be stored?
When the user log in again later, I get the claim of facebook.com and I should get the claim from the application. and merge them?
How is the workflow? Trying to understand claims in practical usage.
Basically, Facebook tells me that I'm john#doe.com, and 'field in the blanks' adds a claim that I'm also a manager of domain.com
then I pass those claims to domain.com?
How should I configure in asp.net the application at domain.com to trust Facebook and 'filled in the blank piece' and request claims from both?
I guess I'm using external providers for Authentication and my own provider for Authorization, how this is created on ASP.NET (web API / MVC)?
UPDATE (for clarification)
Let's get backwards. I create a web application where users can register.
'Somehow' there's an trusted ClaimsBased authority somewhere (this should be another application??) where I request the claims for a particular user to see if have particular rights on my application.
So I imagine something like :
/authserver/claims
and my validation checks if X claim is met to do certain operations.
later I add to Facebook. now I have
/facebook/claims
which tells me the user is X
and
/authserver/claims to see if can do operation X on resource Y.
how this is managed on ASP.NET? and where my own claims should be created/exposed/developed.
I think I'm missing something fundamental here.
I think the important thing to understand is the difference between authentication and authorization.
Authentication - the act of confirming the truth of an attribute of a datum or entity.
Authorization - the function of specifying access rights to resources, which is related to information security and computer security in general and to access control in particular.
So, typically for secured system, the workflow starts with Authentication. When a user first connects/uses a system, then are not authenticated (lets say this user is of a type/group Anonymous). The act of the system determining the user is not authenticated is an Authentication in and of it self. Based on being Anonymous, then the act of the system determining what that type of user anonymous has access too is now authorizing what the user can do. For very secure system, the only access anonymous has is to the login screen/page. Once logged in the user is assigned a unique identity and assigned some type of group policy/role (if not already created).
with a web-based application and having a website (#1) authenticate for another website(#2) it becomes a bit more complicated. When I log into StackOverflow(#1), I use my Gmail(#2) account. I get redirected to Google with some special way for Google to know that the page I came from/to go back to. This could be a special key/url combination or for less restrictive access, usually has to do with return url (after I say, yes, where I go back too). Google will create a special authentication token that is specific to the url I am returning to. It is tied to the URL because that means that my token on StackOverflow won't allow me or anyone else to log into say NewEgg for example (in other words someone at StackOverflow with access to the database can't use my token to authenticate as me on some other website, but technically they could log in as me on StackOverflow, but they own the website, so that doesn't really matter). Now I am authenticated on StackOverflow (but technically StackOverflow doesn't even need to know any information about me, just my Token).
On StackOverflow as a new user, a new account is created. This account probably has a one to many relationship to my unique account on Stack Overflow and multiple of logins (and type of logins, OAuth, OpenID or SO Login). Once the account is created, I have whatever access they have setup by default. If I need more or some trigger (lets say based on my Reputation points :) I now have access to Administrative functionality (given some role). That role is tied to my account and indirectly tied to my authentication. This means that I can create additional logins (say a Local SO Login) but keep my Account.
As for each Authentication resource (Google, Facebook, etc) there will be difference schemes for Authentication, but there will always be at least a token (or more than one token) for a website to say who I am (in a generic way).
So website #1 (Stack Overflow) has requested website #2 (Google) to Authenticate me. But only website #1 knows what am I Authorized for.
For role specific functionality, there are a good number of answer on SO dealing with ASP.Net Identity and the Role Manager:
Creating Roles in Asp.net Identity MVC 5
mvc 5 check user role
A much more Indepth look into Identity with MVC - Extending Identity Accounts and Implementing Role-Based Authentication in ASP.NET MVC 5
If you're using ASPNET.Identity (http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity), you can add a Role claim type to the user. It'll be associated with the userlogin, so when the user authenticates with Facebook, these user claims will be added and available in MVC.
See the following code fragment:
var acRes = await UserManager.AddClaimAsync(userId, new Claim(ClaimTypes.Role, "MyRole"));
An example is say i have a child with lots of data in it and a user wants to attack my firebase to slow it down and increase my upload limit and sets to read this child over and over again not from my app but from their own creation.
How would i prevent this from happening when the child is a public child in that it does not require a user to be logged in to be read?
Is there a way to only allow a certain domain to access a firebase so that other users cannot just access my data from their domains?
Since all the data can be read via javascript and the javascript can be changed by the user can this also happen when someone changes the code on my site. Also is this a potential problem with all databases RDBMS or non RDBMs and not just with Firebase?
You might want to check out the "anonymous" login option provided by Firebase Simple Login: https://www.firebase.com/docs/security/simple-login-anonymous.html - this lets every visitor to your site authenticate with Firebase, and you can setup your security rules such that only anonymously authenticated visitors to your site can read data.
Most production apps will employ the security rules to restrict access to their data. Learn more about Firebase security rules here: https://www.firebase.com/docs/security/security-rules.html
I have been looking and playing with Firebase and I found it really interesting.
So far I have tried some simple authentication and security policy setting but now I have a problem which does not seem to be covered in the documentation and I couldn't find anything on Google or here.
The problem is that I cannot find a way to limit the number of concurrent logins per email/password.
I would like to have an option where paid customers can only login from 1 IP at a time. In other words I don't want people to be able to purchase an account and then share the same with friends and family and then all connect to the system at the same time using the same credentials.
Thank you in advance.
You will control access by writing to a path in Firebase whenever a user logs in. Then you can check that path to ensure only one user exists at a time:
write a value to a path each time a user logs in (e.g. logged_in_users/$user_id)
use onDisconnect() to delete that value when user disconnects
check that path for a value on an additional login attempt
show an error if the value exists or allow login if not
This takes care of the UX portion. To secure it against exploits, you will take advantage of Firebase's comprehensive security rules:
generate your own authentication tokens using the custom login strategy
include the IP address as part of the data inside the token
reject login attempts if the logged_in_users/$user_id is set to a different IP address
write security rules to prevent read/write from other IPs
Assuming you've generated tokens containing an IP address, your security rules could look something like the following:
".read": "root.child('logged_in_users/'+auth.uid).val() === auth.ip_address"
We want to give users peoplesoft portal access from outside network. But ..that access needs to be read only and very limited.
Has anyone done location based role enabling is peoplesoft.. i.e. disable all roles and enable only particular role based on ip address or web server ?
I have done something similar to that using DNS entries to determine internal/external access. The users wanted to force Self-Service access to all users when they logged into PeopleSoft if they were at home, but give the users full access if they logged in via VPN or at their desk. That way, power users would not have full security unless they were authenticated via VPN or at work.
We accomplished by customizing the USERMAINT component, created a new security table for "self service" security, adding custom Signon PeopleCode, and setting up a 2nd DNS entry that was exposed for external access.
To start, the network admin set up two sets of DNS entries that pointed to the PS web servers. For example, psoft.company.com was the internal DNS and only set for local network access, and selfservice.company.com was the external DNS available for global access.
Next, we customized the USERMAINT component (User Profile). We hid the delivered Roles tab and replaced it with a copy. The new page was pointing to a copy of PSUSERROLE. We did this because we want to use the delivered PSROLEUSER table as the "current" security table. If the Security Admin wants to update a users internal (or day-job) security, we want to store if for long term. (This will make more sense below). So the new custom table, say XXROLEUSER, is now the master table for security.
Then, we added record/page/component for the Security Admin to define "self service" security (XXSSROLES). This record/page just stores Role Names for when users log in externally. This allows the Security Admin to update self service security for seasonal changes, like Open Enrollment. The admin can add a role during Open Enrollment to grant additional access, and then remove it when the period has ended.
Last, we created a custom Signon PeopleCode step that handles the internal/external security switch. The Signon PeopleCode grabs the URL used to log in. The code parses the URL to see with DNS entry was used to access the system. If the DNS entry is "selfservice.company.com", the code will clear our the rows in PSROLEUSER for the user and insert the roles from the XXSSROLES table. If the DNS entry is "psoft.company.com", the code will clear out PSROLEUSER and insert the roles form the XXROLEUSER table.
This code change turns PSROLEUSER into a transaction table. Because the Tools system relies on this table for many different security functions, it is important to create a copy to use as the "master table" for use in the User Profile component.
If this is something you are interested in trying, I'd be happy to post some sample code for the Signon PeopleCode.
I uploaded the Signon PeopleCode function to GitHub (see link below). You can create a custom record to store the PeopleCode and then add it into the Signon PeopleCode page. If you need more information, let me know. I am not able to post the entire tech spec, but I'd be happy to help if you have questions.
http://github.com/iversond/PeopleTools-Dynamic-Login
Recruiting Solutions uses a similar process - when creating the external Candidate Gateway to allow applicants to apply for positions, a 'guest' ID is created for a particular web server that has severely restricted permissions - basically just the external applicant apply objects.
In PS 9 , have a look at PeopleTools > Web Profile > Web Profile Configuration under the security tab. You can definitely secure the system at a web server level.
HTH
Disclaimer: I work for the company.
A bit late to the party, but a useful answer: IntraSee has developed a solution for this exact situation.
The key is that you need to be able to define rules (locations) and then tie those to specific roles. Evaluated at login, the roles are revoked or granted depending on the rules and user location. It can use IP or other attributes to determine roles.
To do this manually is slightly tricky as you need to account for the versioning of the user profile and associated permissions. Signon PeopleCode is the best place to evaluate these rules as you can do it once per session, and you ahve access to the business data to make correlative decisions. E.G. if a person has a huge approval limit, maybe they can't approve remotely, but someone with a small limit can. Same security access, but add or revoked based on location and data.
To your specific case: you would have base roles with read only access to those users, then a set of 'opt-in' roles that gave read/write. When they come in from the correct location, they get the read/write. So, we are only adding the extra access when appropriate.
I would create a separate site ( like the candidate gateway suggestion ), it will need a similar web profile as the one you are currently using, no other changes would be necessary.
Next create a custom menu, then attach all of the components you wish to make read-only.
Register the content references for those custom_menu.components.
Create Roles and Permission Lists adding the custom_menu.components then select "Display Only". Then assign the roles to the users.
Expose that site via the firewall.
That's it.