I am attempting to programmatically create federated user account and setup that user account using automation.
The reason for this is because we would want to create customized user environments (by logging in the user).
By Default when a domain is federated at IBM, the user account at that domain is not created, the user has to login for the account to be created. See notes from Documentation:
I want to have the user created so automation scripts can provision services and resource using Schematics SDK (Workspace)
I found that the user can be logged in and trigger account creation by using CLI
https://cloud.ibm.com/docs/account?topic=account-federated_id
The program is that when using CLI, it prompts for a one-time code for SSO logins (federated)
It says to avoid the one-time codes for automation scripts, you have to use API key
https://cloud.ibm.com/docs/account?topic=account-federated_id#api_key
However you can only get the API key after the user has been created. Which brings me to this question.. how do we get the API key before getting the user logged, is there a way programmatically or what have others done in python to get around this one-time token prompt to log in the federated user so that their environment and account is created for schematics and other automation scripts to deploy instances etc.?
Related
I'm trying to make an app and I can't figure out how to sign in to a user with the python library firebase_admin. I don't have any code as of this moment. Let me know if you can help me out.
The Firebase Admin SDK is designed to be used in a trusted environment, such as your development machine, a server you control, or Cloud Functions/Cloud Run. It gets its authorization from its context or from a credentials file that you provide to it, and which gives it full, administrative access to the project. Therefor it doesn't need, and doesn't have a way, to sign in as a specific user.
If your use-case requires that you sign a user in to Firebase from your Python code, you can consider calling the REST API to authenticate. But the use-case for this would typically be to then pass the ID token you receive back to a user (similar to the use-case in creating custom tokens).
I have a OneDrive for Business user account within a large organization. I'd like to have a daemon service running (Python) that automatically uploads files to this user's OneDrive.
This service will be running in a headless VM, so browser-based authentication (especially if it needs to be done more than once) is very difficult.
What are my options for authenticating this app to allow it to write to the user's OneDrive? I've registered an app and created a client secret for it. I was experimenting with the authorization flow described here, but that SDK is deprecated and no longer supported, so I'd prefer to use Graph if possible.
What are my options for authentication with Python in this scenario, and is any sample code / example available?
Both delegated and application permissions are supported on MS Graph API: https://learn.microsoft.com/en-us/graph/api/drive-list?view=graph-rest-1.0&tabs=http. Application permissions might not be acceptable for your use case since they would allow access to all users' OneDrives?
Application permissions would definitely be the easiest choice.
But you can also implement this scenario using delegated permissions
You would need the user to initialize the process by authenticating interactively once.
When they do that, store the refresh token in a secret store accessible by the server application.
Then it can use the refresh token to get a new refresh token + access token when needed.
This approach has some more complexity but does allow you to only give access to this one user's OneDrive for the app.
Also, keep in mind that refresh tokens can expire.
The user would need to re-authenticate if that happens.
If this process is critical, application permissions can be a really good idea despite the downsides.
I want to have access to a specific work user's OneDrive. I could register an application in Azure AD and assign one of two types of permission(delegated or application).
Based on the Microsoft Documentation if I register an app with the application-level access it could have access to all users' drive and based on this question in Stackoverflow there is no way to limit this access to a specific drive. So I ignored this approach.
On the other hand, based on the Microsoft Documentation if I want to assign delegate permissions to the defined app I have to manually approve the access list on the consent page. This is not desired for me as I'm looking for a code-base solution which runs behind the scene regular bases.
Is there any solution that I could have access to a specific OneDrive by python code?
If you want to connect with only 1 user's Onedrive you can use ROPC flow which can work in your scenario. But this is not recommended by microsoft because of security concerns. And yes, if you have MFA enabled, you cannot use it.
One of the good recommendations can be to use Graph API for OneDrive.
For example, one of the use case can be to Get current user's OneDrive:
The signed in user's drive (when using delegated authentication) can
be accessed from the me singleton.
If a user's OneDrive is not provisioned but the user has a license to
use OneDrive, this request will automatically provision the user's
drive, when using delegated authentication.
Http Request:
GET /me/drive
Resources that will help you to call Graph API from Python:
https://github.com/microsoftgraph/python-security-rest-sample
Edit:
Further, I have found a way in which you can disable user consent.
To configure user consent settings through the Azure portal:
Sign in to the Azure portal as a Global Administrator.
Select Azure Active Directory > Enterprise applications > Consent and permissions > User consent settings.
Under User consent for applications, select Do not allow User Consent.
Select Save to save your settings.
If you want consent permissions other than this, you can design your own Consent.
I am running a research project where we create the participant's Jawbone accounts. I am writing a piece of program that captures all of the participants' step counts. I am wondering how I can feed the username and password without having this page below pop up.
In essence, I want to streamline the process so that I can get the oauth access token without any user manual input. I am writing all of this in Python (Google App Engine).
The only way to avoid that page is to have already stored the OAuth tokens for the user. As part of the OAuth protocol, each user has to grant your application access to the data.
How are you planning to gather the users' accounts and credentials?
I would recommend that instead of gathering users' emails and passwords manually, you:
Build a simple sign up flow in your app according to the UP Authentication doc.
Have your users run that flow
Save their OAuth tokens for later use
I migrated away from Google App Engine several months ago. But I am still relying on it for authentication, because my users are identified by their user_id attribute on GAE.
For this purpose my (now external) applications redirect the user to a Google App Engine application using a encrypted, signed and timestamped login request. The GAE application then performs the login using GAE's "Users" service. After successfully being logged-in on GAE, the user is again redirected using a encrypted, signed and timestamped response to my external application.
The rudimentary implementation can be found here and here. As you can see, this is very basic and relies on heavy crypto that leads to bad performance.
My external applications, in this case Django applications, are storing the user_id inside the password field of the user table. Besides the user_id, I only get the email address from GAE to store username and email in Django.
Now I would like to remove the dependency on the GAE service. The first approach which comes to mind would probably be to send an email to each user requesting him to set a new password and then perform my own authentication using Django.
I would prefer a solution which relies on Google's OpenID service so that there is actually no difference for the user. This is also preferred, because I need to send the user to Google anyway to get AuthSub tokens for the Google Calendar API.
The problem is that I couldn't find a way to get the GAE user_id attribute of a given Google Account without using GAE. OpenID and all the other authentication protocols use different identifiers.
So now the question is: Does Google provide any API I could use for this purpose which I haven't seen yet? Are there any other possible solutions or ideas on how to migrate the user accounts?
Thanks in advance!
The best way to do this is to show users a 'migration' interstital, which redirects them to the Google OpenID provider and prompts them to sign in there. Once they're signed in at both locations, you can match the two accounts, and let them log in over OpenID in future.
AFAIK, the only common identifier between Google Accounts and Google OpenID is the email.
Get email when user logs into Google Account via your current gae setup. Use User.email(). Save this email along with the user data.
When you have emails of all (most) users, switch to Google OpenID. When user logs in, get the email address and find this user in the database.
Why don't you try a hybrid approach:
Switch to OpenId
If your application already knows the userId, you are done
If not ask the user, if he has an account to migrate
If yes, log him in with the old mechansim and ttransfer the acount
If not create a new account
Google has a unique identifier that's returned as a parameter with a successful OpenID authentication request - *openid.claimed_id* . If you switch to using OpenID you could essentially exchange the user_id for this parameter the first time a user logs in using the new method without the user noticing anything different about their login experience.
Documentation for the authentication process is outlined here. I'd recommend using the hybrid OpenID+OAuth approach so that you can associate your request token with a given id, then, upon return, verify that the openid.claimed_id matches your original request token.