I'm using AuthFlow='ADMIN_NO_SRP_AUTH' to set up Cognito MFA authentication.
I wonder if Is there any way that I can ignore the MFA authentication?
Which AdminInitiateAuth request should I use?
For example:
I create a user, then register that user to my UserPool, enable MFA for that user, and now MFA is working fine.
But what if on a bad day, I don't want to use MFA Authentication anymore, but I also don't want to disable MFA for my user because I want to use it on another beautiful day.
May not be the answer you are hoping for but... You can't do it. And it wouldn't even make sense.
The MFA is either enable or disabled. If it's enabled, you need to authenticated with it. Think about it. You set it up to protect user's account. But the user is able to say - oh, I actually don't want to use it just this time.
The thing is - a bad actor could do exactly the same. Just send a request saying not to use MFA. That would defeat the purpose of MFA entirely.
That's why this decision is left to either an administrator of the pool or the user who can disable it, but only as long as he/she is signed it (depending on pool's configuration).
That's why you can only either have it enabled or disabled. And you cannot disable it ad hoc per request.
Related
I've implemented 2-factor authentication in my ASP.NET Core application. Yesterday I implemented the use of recovery codes, to be used in case a user loses his device.
My question is actually pure theoretical.
If a user has used a recovery code, we don't want to disable the 2-factor authentication. But in order to disable 2FA, the user needs to generate a verification code using his mobile phone. So he will not be able to turn off 2FA in any way.
So the only thing to do for someone who has lost his device is to keep using backup codes, keep an eye that they don't run out, and generate new backup codes in time (which he has to write down again). Or ask the administrator to disable 2FA for him. But isn't there a better way to deal with this kind of cases?
I ended up doing the following:
Enable 2-factor authentication: Obviously, here you request a verificationcode
During login: Request verificationcode, but also allow TwoFactorRecoveryCodeSignInAsync
Disable 2-factor authentication: Allow both verificationcode and recoverycode
Bypass 2-factor authentication for external logins + Generate new recoverycodes: Only allow verificationcode
If our user has MFA enabled in cognito and they file a support case where we as the admin would have to 'impersonate' their account to see what is going on. How would that work? There doesn't seem to be a temporary disable of MFA in cognito right? Would we have to request that the user disable MFA on their end before we can use our endpoints to impersonate the login?
There is no way to "impersonate" the user with or without MFA unless the user is willing to give you their credentials! Then you can theoretically also convince them to give you their MFA as soon as they recieve it. But all of this would really bad practice. You should look for alternative like creating a dummy account and trying to recreate the issue that a user is facing. If you could give details about what you are trying to achieve by impersonating the user, maybe we could figure out some alternatives.
We want to allow our users to retrieve a set of temporary CLI credentials for a given AWS role by signing in to OneLogin with password and MFA. We have a working solution, but it requires the user to fully re-authenticate to OneLogin (including MFA) every 60 minutes as the AWS temporary credentials expire. I think that won't fly - our users are accustomed to permanent API credentials tied to a real IAM user.
Ideally, we'd like to allow users to authenticate once a day, securely cache the resulting SAML assertion, and use that to transparently refresh the AWS API credentials as needed. I'm thinking of something like aws-keychain that would use the local OS credential store to remember the SAML assertion, and only prompt the user for input when their OneLogin session has timed out.
This almost works as-is. The catch is that the SAML assertion returned by OneLogin's saml_assertion and verify_factor endpoints sets a three-minute deadline on the Subject and Conditions fields.
Is there a way to do what we want, or are we trying to route around a core SAML principle?
The accepted answer here is no longer true. It is now possible to authenticate the user and verify MFA once at the start of a session and then have the session refreshed on an hourly basis without having to enter further MFA tokens.
To do this you must use the --loop parameter of the CLI tool and have a corresponding App Policy in OneLogin that enables the "Skip if OTP received within last X minutes" setting.
https://developers.onelogin.com/api-docs/1/samples/aws-cli
We're in the process of officially adding an option to in our official CLI tool to re-use the user credentials similarly to what you're describing.
Essentially our CLI tool has an option to reuse the user/pass in the background to continuously refresh the access info in a user profile so while the user will provide credentials once, the access info will get updated before it expires.
But unfortunately, at least at this time, there's no way to get around the MFA part if the application policy requires MFA. It'll need that MFA to refresh the credentials.
If you have to have MFA, you can always use the OneLogin MFA APIs to bake in an MFA flow into the tool...
Check it out here: https://github.com/onelogin/onelogin-aws-cli-assume-role/pull/5
Everything I'm reading shows that in order for an application to use onedrive, it has to do the oauth2 thing to get credentials. But what if you're a batch process and don't have a web interface for your users.
Google's API has a special type of account called a service account where once you set it up, you can control access to everything from that one account, no need to interact with users. Does such a thing exist for onedrive?
App-only authentication doesn't require the user be prompted for credentials but it also isn't supported in 100% of scenarios. For example, the APIs need a user principle for creating special folders and resolving a user's personal site. Also, it is only supported for OneDrive for Business, not Consumer. Consumer always requires the user be prompted for initial authentication.
Another option would be to spin up a web service of some sort that handles initial user authentication, ie. a sign up page. With that, you can retrieve a refresh token for offline authentication and store it for the user. Every authentication from then on can be done using the refresh tokens, which doesn't require a user prompt.
I finally found this. It's the same basic idea as google's service account, but I think it's harder to use. But at least the concept is supported.
http://blogs.msdn.com/b/exchangedev/archive/2015/01/21/building-demon-or-service-apps-with-office-365-mail-calendar-and-contacts-apis-oauth2-client-credential-flow.aspx
I recently ran successfully the spring-saml-sample working with ADFS 2.0.
However I noticed that ADFS only ask me once my user/pass, and then I can enter as many times I want but always with the same user (even when I did a global logout).
Is seems there is a cookie or something stored locally that is sent to ADFS.
What if I want to authenticate with a different user on the same machine? How can I configure saml-extension in order to force authentication again?
SAML contains a mechanism for forcing IDP to re-authenticate user called forced authentication. You can enable it by setting flag forceAuthn in WebSSOProfileOptions to true. You can find more details on setting this in the Spring SAML manual, chapter 9.2.1.
In addition to Vladimir's answer, if you are able to continue login even after global logout has been done, you should check that as well. After global logout all SP and IDP sessions should be deleted and so ideally you should not be able to use the site.