I am now hosting Pre-Packaged+Identity+Server+5.2.0+with+API+Manager+2.0.0 [https://docs.wso2.com/display/CLUSTER44x/Configuring+the+Pre-Packaged+Identity+Server+5.2.0+with+API+Manager+2.0.0] in my own AWS instance.
Planning to move on to managed Cloud solution by WSO2. But I can see independent installatiion of identity server and wso2 api manager. But is there a cloud alternative for idenitity server , api manager combo.
I am using WSO2 idenity server for user management only.keeping users in that. Can it be done in API manager as well?
What is the cloud alternative for this?
WSO2 Cloud uses Identity Server for providing Single Sign On. Cloud has its deployment architecture done in a way API Manager can also do the user management (thats comes with the power of WSO2 platform). You dont need to worry about cloud having the API Manager and Identity Server separately.
IF you are managing your subscribers and publishers, then its an out of the box scenario in the cloud. If you want to store end users of the APIs (i.e. if you are using the password grant type), then you can add a secondary userstore and store the end users in it.
I recommend you to raise these questions via the "Contact Support" option available in the Cloud UI.
Related
I am using firebase admin sdk on the server to generate sign in links and send them out via custom SMTP api.
I just glanced at https://firebase.google.com/docs/auth/limits and I am well within these, but I believe there is nothing stopping a malicious third party from creating/requesting sign-in links via front end code. Is there a possibility to disable this functionality so it is only available to admin acc?
Additionally, I'd like some emails (i.e. multi factor enrolment) to not be possible, but again, given that someone can obtain some of my firebase front end details, they technically can send these?
You can restrict the API key from accessing an API (e.g. Identity Toolkit) but not disable a single method of the API for client.Sign up and delete user can be (that requires upgrading to Identity Platform) .
Firebase generates an API key when you add a web app. You can either update that or create a new key from API Credentials console.
You can then restrict what the API key in Firebase web config has access to:
However, Firebase Auth Client SDK will not work as Identity Toolkit is not selected. You'll have to proxy the requests through your backend and use a different key that can be used from your server's IP only.
Firebase Admin SDK will still be functional as usual so you can use that to perform other operations like updating/deleting users. You'll just have to write APIs on your backend for what could have been done using client SDK directly (or use Admin SDK when possible).
It might be a lot to update and I would not recommend unless you are facing rate limiting issues where Firebase Support should be able to help.
I want to use the Firebase Admin SDK in my GCP cloud function, specifically for creating custom auth tokens.
I was getting auth/insufficient-permission errors after deployment and got to this thread. Note that it talks about Firebase functions, while I use pure GCP Cloud Functions.
To my understanding, GCP Cloud Functions uses the default App Engine service account, which is missing the Firebase Admin SDK admin service agent role.
I manually added it through the GCP console and it seems to solve the issue, but now I want to automate it via terraform where I manage my infrastructure.
How do I access the default App Engine service account? I think it's auto created when the GCP project is created.
How do I add the relevant role to it without changing other service accounts using that roles?
Is this it right approach, or is there a better way I'm missing?
The relevant documentation I was looking at is here. Note that I'm using initializeApp() without arguments, i.e. letting the library to discover the service account implicitly.
How to get the default App Engine service account through Terraform: google_app_engine_default_service_account
How to work with 'additional' IAM roles assigned to a service account:
IAM policy for service account
For general recommendations - I would prefer to use a specifically created service account and completely delete (or disable) the default App Engine service account.
Edit ==> Additional details as requested
Here is a description of Cloud Function service account in runtime:
The App Engine service account has the Editor role, which allows it broad access to many Google Cloud services. While this is the fastest way to develop functions, Google recommends using this default service account for testing and development only. For production, you should grant the service account only the minimum set of permissions required to achieve its goal.
Thus, it may be useful to delete/disable App Engine service account, create a specific service account for the given cloud function, assign it all relevant minimum of IAM roles, and use it.
As a side note I also would suggest to delete/disable the default Compute Engine service account, delete the default network with all firewall rules and subnetworks... But this is a separate story.
I am trying to integrate a google service account to a firebase project for a web application.
How can I integrate it to firebase project directly(to the backend) so that I can use APIs without API-key
By using Firebase in your project, you get access to a set of client-side APIs that you can use directly in your application without needing to include the Google Service Account. Most Firebase products rely on a separate user-authentication mechanism, and their own server-side security rules language to control what data each user has access to. So there should be no need to include the Google Service Account credentials in your application code.
If you have a specific Google API for which no Firebase SDK exists, you can call that API from something like Cloud Functions. In Cloud Functions you can securely use your service account, and then expose just the required functionality to your application code.
I have a simple web site hosted in Firebase and it is making AJAX calls to REST API endpoints in GCP Cloud Run.
I would like to limit these endpoints only to the calls coming from this site hosted in Firebase. Any call coming from any other origin should not be able to use the endpoints. What is the best way to do this?
When I was not using GCP Cloud Run, I was doing a host check on the API side to make sure that request is coming from my client but now with Cloud Run this is not possible. What else could be done?
Please note that the web-site hosted in Firebase is very simple and do not do any user authentication.
Challenge: Restrict access to a Cloud Run service to a single web application, without relying on:
Restricting access to the web application
Imposing authentication on users
This difficulty is not specific to Cloud Run. It's a general challenge for static sites backed by APIs, and a reason why many sites have authentication. As mentioned in the question comments, a server-side "host" check is not a meaningful security layer, as everything in the HTTP request can be faked. I strongly recommend you not worry about keeping your API private or add user authentication to keep the system simple and access accountable.
If that's not possible, you can still take the authentication approach by creating a single user, embedding the credentials in the site, and rotating them regularly (by redeploy to Firebase Hosting) to prevent credential theft from having indefinite access to your API. Having Firebase Auth in the middle is better than a simple API key because it prevents replay attacks from accessing your API.
I want to use datastore of google in my web app but do not want to host it in google app engine, I want to host it some other machine. So how i can use datastore in such web app ?
will it be more economical ?
You would need to follow the Accessing the Cloud Datastore API from another platform procedure:
This section shows how to activate and access the Cloud Datastore API
from an external application running on a platform outside of Google
Cloud.
Enable the Cloud Datastore API for the project. You can enable the API for an existing project, or create a new project and then enable
the API.
Enable the Cloud Datastore API
To use the Cloud Datastore API, your Cloud project requires an active App Engine application. Open the App Engine dashboard and
confirm your Cloud project has an active App Engine app.
Open the App Engine dashboard
Create an App Engine app if needed. The app must not be disabled.
Go to the Create service account key page.
Click the drop-down box below Service account, then click New service account.
Enter a name for the service account in Name.
Use the default Service account ID or generate a different one.
Select JSON in Key type.
Click Create.
Upon successful creation, your browser will download the private key. The Cloud Platform Console provides a prompt that displays the
private key file name. Note the file name so you can locate it, then
click Close to dismiss the prompt.
Your Service Account is the Email address displayed under the Service Account section.
Your Private Key is the file you just downloaded.
At this point all services and authorizations are configured for your
project and you can start writing code or exploring the API.
You don't actually need to write code for the GAE app and deploy it, see Is an App Engine instance required for accessing Datastore?
As for being more economical or not (I presume compared to running the app on GAE) - it depends a lot on the app's usage/scale, what the app does and how it does it.
Have a look at Cloud Endpoints
https://cloud.google.com/appengine/docs/java/endpoints/