We have a monolith application and looking to decouple the authentication / authorization service.
At this stage, authorization is the simplest to start with.
The problem comes with authorizing certain type of access to resources. e.g. a user can edit only his own posts.
Given that the microservice will hold only roles/auth items and assignments to an user id, does it make sense to create the following endpoint?
POST v1/<userEmail>/authorize/<authItemName>
with data, e.g.
v1/user#company.com/authorize/Posts.UpdateOwn`
{
post: {
content: 'My first post'
...
creator: {
email: user#company.com
}
}
}
Where we would send the object's data and the user's data. That way I can have a rule that would return true if object.creatorId === userData.id however if you think about it, it seems pretty dumb... if the monolith already has the info, why not just check for
the general permission Post.Edit and also checking that the user is the creator.
Is there a better approach for this?
I'm setting up an online survey. This survey will be anonymous - to fill it all you need to have is the survey's URL. I want to store the survey answers in Firestore, and later run scripts that retrieve the data and generate reports.
I want to set it up so that everybody can write to it, but only specific accounts that have access to the project can read the data. I've set up the following rules:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read: if request.auth.uid != null;
allow write;
}
}
}
Now I want to create the script that reads the data, and I'm not sure - which API key should I use? Firestore automatically created a firebase-sdk-admin service account - should I use this account? There are also the Browser Key and Web client Key that were created automatically. Are those the ones to use?
What I would really want is to set up the script in a way that asks me for my Google Credentials (much like the gcloud sdk does it). That way there's no sensitive information in the script at all - if the script user logs in to Google with an account that has access to the database - it works. If it doesn't - it doesn't.
Can I do that?
You can either user Firebase Custom Claims which are basically like roles in Discord so or store UIDs of authorized users in Firestore or RTDB. Then you can write you security rules like this:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read: if request.auth.uid != null;
allow write: if request.auth.token.admin == true;
}
}
}
Now only the users with "admin" claim set to true will be able to write to those documents. If you go with storing the user UIDs in a Firestore document then you can check if user's UID is present their as shown below:
allow write: get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
Regarding the Service Account, you should not use them from frontend. They grant privileged access to your Firebase resources i.e. security rules are redundant. So you usually use them with the Firebase Admin SDK in a secure server env like Cloud functions. You can create a Firebase Cloud Function and then allow only whitelisted users to invoke it. That means if unauthenticated users or someone you haven't whitelisted won't be able to invoke it.
If you want to give access to your database to a teammate, then you can add members to your project from the Firebase Console. Let me know if you have any further queries.
I think I got it. Since I want to let everybody write, and only read data from scripts run by admins and not users, I can set up the following access rules:
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read: if false;
allow write;
}
}
}
For reading, my scripts will authenticate as a service account (keeping the service account json file a secret), and will be able to read the data properly.
I am trying to understand on how to extend the wolkenkit auth layer.
Say i want users with different roles: normal, moderator and admin.
normal users can see and modify their own content, but aren't allowed to modify content from other users.
moderator users are allowed to modify all entries, but don't have permission to delete anything than their own content.
admin users can modify and delete everything.
There are also unauthenticated guest users who can read everything but modify nothing.
Reading the docs for Write model: Configuring authorization i can model the guest/normal use case by writing something along the lines of:
const initialState = {
isAuthorized: {
commands: {
issue: { forAuthenticated: false, forPublic: false }
},
events: {
issued: { forAuthenticated: true, forPublic: true }
}
}
};
For my requirements i would need additional roles defined in this object. Something like { forModerator: true, forAdmin: true }.
There is also Granting access from a command to change permissions at runtime, but i am not sure if that would work. Even if it does, that feels quite hacky.
Is this somehow possible?
Disclaimer: I am one of the developers of wolkenkit.
To cut a long story short: No, right now unfortunately this is not possible, but this feature is on our roadmap. At least today, I can't tell you when this will be available.
Your best option would be to do it on your own. One way to do this might be to use your identity provider to include a moderator claim in the JWTs of the moderators, and then handle this in the command handler appropriately.
In the command handler you have access to the token by
command.user.token
so you can get the claims as needed. I'm very sorry, that there is no better answer right now :-(
I once enabled the _user database in my cloudant account to try out some things (via the HTTP PUT call to _security https://cloudant.com/for-developers/faq/auth/ last Paragraph), but now I would go back to the regular cloudant authentication. How can I make this happen?
You can enable regular Cloudant authentication by removing the "nobody" roles from the _security object. The "nobody" roles essentially let anyone through Cloudant's auth layer, so CouchDB's can kick in.
To do this you need to PUT a JSON document like the following to the _security endpoint of the database (for example https://USERNAME.cloudant.com/DATABASE/_security):
{
"cloudant": {
"nobody": []
}
}
I just got some feedback from the cloud ant IRC chat.
To reset the authentication system to the cloudant system I had so
PUT the following document to security
{
"cloudant": {
"nobody": []
},
"readers": {
"names":[],
"roles":[]
}
}
Thanks to user mikerhodes
I want users to be able to authenticate to my Firebase application using multiple different auth providers, such as Facebook, Twitter, or Github. Once authenticated, I want users to have access to the same account no matter which auth method they used.
In other words, I want to merge multiple auth methods into a single account within my app. How can I do this in a Firebase app?
Update (20160521): Firebase just released a major update to its Firebase Authentication product, which now allows a single user to link accounts from the various supported providers. To find out more about this feature, read the documentation for iOS, Web and Android. The answer below is left for historical reasons.
The core Firebase service provides several methods for authentication:
https://www.firebase.com/docs/security/authentication.html
At its core, Firebase uses secure JWT tokens for authentication. Anything that results in the production of a JWT token (such as using a JWT library on your own server) will work to authenticate your users to Firebase, so you have complete control over the authentication process.
Firebase provides a service called Firebase Simple Login that is one way to generate these tokens (this provides our Facebook, Twitter, etc auth). It's intended for common auth scenarios so that you can get up and running quickly with no server, but it is not the only way to authenticate, and isn't intended to be a comprehensive solution.
Here's one approach for allowing login with multiple providers using Firebase Simple Login:
Store one canonical user identifier for each user, and a mapping for
each provider-specific identifier to that one canonical id.
Update your security rules to match any of the credentials on a
given user account, instead of just one.
In practice, the security rules might look like this, assuming you want to enable both Twitter and Facebook authentication (or allow a user to create an account with one and then later add the other):
{
"users": {
"$userid": {
// Require the user to be logged in, and make sure their current credentials
// match at least one of the credentials listed below, unless we're creating
// a new account from scratch.
".write": "auth != null &&
(data.val() === null ||
(auth.provider === 'facebook' && auth.id === data.child('facebook/id').val() ||
(auth.provider === 'twitter' && auth.id === data.child('twitter/id').val()))"
}
},
"user-mappings": {
// Only allow users to read the user id mapping for their own account.
"facebook": {
"$fbuid": {
".read": "auth != null && auth.provider === 'facebook' && auth.id === $fbuid",
".write": "auth != null &&
(data.val() == null ||
root.child('users').child(data.val()).child('facebook-id').val() == auth.id)"
}
},
"twitter": {
"$twuid": {
".read": "auth != null && auth.provider === 'twitter' && auth.id === $twuid",
".write": "auth != null &&
(data.val() == null ||
root.child('users').child(data.val()).child('twitter-id').val() == auth.id)"
}
}
}
}
In this example, you store one global user id (which can be anything of your choosing) and maintain mapping between Facebook, Twitter, etc. authentication mechanisms to the primary user record. Upon login for each user, you'll fetch the primary user record from the user-mappings, and use that id as the primary store of user data and actions. The above also restricts and validates the data in user-mappings so that it can only be written to by the proper user who already has the same Facebook, Twitter, etc. user id under /users/$userid/(facebook-id|twitter-id|etc-id).
This method will let you get up and running quickly. However, if you have a complicated use case and want complete control over the auth experience, you can run your own auth code on your own servers. There are many helpful open source libraries you can use to do this, such as everyauth and passport.
You can also authenticate using 3rd party auth providers. For example, you can use Singly, which has a huge variety of integrations out-of-the-box without you needing to write any server-side code.
I know this post exists for months but when I faced this problem, it took lot of my time to make the code more flexible. Base on Andrew code above, I tweaked the code a little.
Sample data store:
userMappings
|---facebook:777
| |---user:"123"
|---twitter:888
|---user:"123"
users
|---123
|---userMappings
|---facebook: "facebook:777"
|---twitter: "twitter:888"
Security rules:
"userMappings": {
"$login_id": {
".read": "$login_id === auth.uid",
".write": "auth!== null && (data.val() === null || $login_id === auth.uid)"
}
},
"users": {
"$user_id": {
".read": "data.child('userMappings/'+auth.provider).val()===auth.uid",
".write": "auth!= null && (data.val() === null || data.child('userMappings/'+auth.provider).val()===auth.uid)"
}
}
So userMappings is still the first information we look up when login by Facebook, Twitter.... the userMappings' user will point to the main account in users. So after login by Facebook or Twitter, we can look up the main user account. In users we keep list of userMapping that can access to its data.
When create new user, we have to create an account in users first. The id for user in users could be anything we want. This is flexible because we can provide more login method like Google, Github without adding more security rule.
I've just created an angularfire decorator to handle this for us: angularfire-multi-auth
I've spent quite some time thinking in a good solution, and IMHO to be able to register from any provider is just confusing. In my front end I always ask for a email registration, so a user logging with facebook and google+, for example, would be logged as the same user when he informs his email.
This way, the Sample Data proposed by Kuma don't need to duplicate the userMappings.
Sample Data Store:
userMappings
|---facebook:777
| |---user:"123"
|---twitter:888
|---user:"123"
users
|---123
|---user data