The simplest OpenShift account offers up to three applications.
How would I give access to a third party, restricted to only application? They need to be able to deploy code to only that one app.
I could create a second set of SSH keys - but it seems that keys are account level access: i.e. all applications on that account.
I could create an Authorization token - but that's also at account level.
I could just share the SSH details of the application - but then when I want to close access, how would I change the details?
Feel like I'm missing something obvious here.
Thanks in advance for any pointers.
ssh keys are the way to go. The third party can provide you their public key so you can add them to your account. Then, you can give them the UUID and App URL (or git url) for just that one app. They do potentially have access to all gears within your account, but realistically, its safe to assume they can't guess the UUID of your other apps.
To revoke access, just delete the public key from your account.
Related
Here is my scenario. Imagine there is a Yoga studio that uses a professional booking and reservation system that exposes an API. Through this API an application can make a reservation for a client. The API takes the client's userid and password to make the reservation. The booking API doesn't use OAuth or any social media sign-ins.
My desire is to create an Assistant Action that would retrieve the list of classes and allow the client to make a booking.
My puzzle is what design/architecture to look towards to supply the userid/password pair required by the booking API.
How have others solved this puzzle?
Should I store the userid/password as "user state" associated with the action?
First, you should have a conversation with the API provider about why they don't provide an OAuth-based solution. This is a security vulnerability waiting to happen, if it hasn't already.
Second, you need to think very carefully about your own risk profile in this case:
Google does not allow you to collect credential information (ie - passwords) through your Action.
Because of this, you must use Account Linking to authenticate them.
This means that you will need something (ie - a database or data store) to manage their account on your side.
This database would be a good place to keep the username/password you need to use for them for the API...
...but it now means that you need to take extreme care about protecting this database.
You don't really say how this API allows for accounts to be created and managed. If these accounts are just used for you (ie - the user doesn't necessarily see them), then you can mitigate some of that risk by treating the username/password as an opaque token that you manage and generate and that the user never sees.
If this is something that the user is aware of, then you'll need to approach the account linking in one of two ways:
Have them log into your service via an app or webapp using this credential info that you will need to save (ack!) and then link to the Assistant using OAuth.
Have them log into your service via an app or webapp using Google Sign-In, which will carry over to your Action. Then have them provide the credential info for the API, which you will need to save (ack!).
I’ve built a google action that talks to my bespoke web Api.
The actions code currently has personal details hard coded into it. I need to make it so that when someone uses it for the first time it asks them for a username password and URL.
Is there a way to do this? Or maybe there is a way for a user to add those details to there google account in some way that the action can read them.
Alternatively is there a way to publish an action so only specific users can access it?
In general, asking for a username and password is a bad approach for Actions, for several reasons, and asking for a URL can be quite a mess. Particularly if you're expecting the user to access the Action via voice or a device that doesn't support a keyboard.
The better approach is to use Account Linking to connect their Google Account to an account they have created on your system. If you need additional one-time configuration information, you can have them provide this information for their account via a webapp, store it in a datastore of some sort, and then access it when they contact your webhook via the Action.
There is no way to have the Assistant enforce access to a production Action. You can publish an Alpha release to up to 20 accounts, but this is still treated as a "test" version.
I'm using adjust and firebase in my ionic app but the app secrets for these integrations and others all show up in my app's js code if I extract the APK/IPA.
How do I keep credentials secure and package them with the app's APK/IPA for such hybrid apps?
This is an interesting question and it's good that you are asking it :)
For the Firebase settings, they are secret, but not secret-secret. They are just a starting point. Nothing can be done with those unless the user also logs in with their password which is hashed using the secret key and then sent over.
This proves that the person knows enough to identify themselves as a user.
Then on the server side, you have your rules that say "for the person that has identified themselves as user X they have permission to do Y"
If somebody has got your password then you are exposed just the same as you are always exposed.
You can also restrict your Firebase account by apps package id, hostname, IP address, in the Google Cloud admin panels.
As for your other things, like Adjust, they have their own solutions along the same lines. Either the API key is just enough for you to read the information, or if its a powerful level of access then normally there is some kind of authentication/account linking process so you can prove yourself to the other API.
If not, then you cannot just put it out there, you need to create your own proxy. Firebase supports cloud functions (aka serverless) so you can run snippets of code which are only accessible by users that have logged in, and then return that information back to the client as a proxy.
My company has userbase of course, but I want to allow users to login and use my applications with their social accounts e.g. Outlook, Facebook, Gmail. Something that is usually not clear to me when I read resources on the Internet on the topic is how to map the social credentials with ones in our database? I know we should use an API platform or something like that, but the user identity part is not clear to me.
You basically need to, as you noted, tap into the provided response and transform or link or provision it to existing identities in your own userbase. A lot of this depends on your method of delegating authentication to external provides and things they expose back to you as part of the user profile. You basically need to grab the user profile, parse it and then determine which field can be used to link that profile to an existing account, and then establish the authentication session based on the final result.
Here is a link to a technical walkthrough that describes the same process with an SSO solution: https://apereo.github.io/2018/04/20/cas-delegated-authn-account-linking/
I've just integrated my app with IBM's SSO via Cloud Directory. The idea here is that I want access to be very secure and only authorized users (pre-approved) can access the application (e.g. website in this case).
However, I've just realised now that anyone that goes to the app's webpage can, instead of logging in, just select "Register New User" and fill in some details and he's given access? Is there a way to:
1) EITHER keep that registration form, but require one of the admins to approve it before access is given? (better solution)
2) OR completely remove the self-registration option?
As the current situation is far from secure for what I need.
Thanks a lot!
I talked with the support team and that is the best (only) way to do it, just remove the links from the HTML templates.