In our environment someone have changed the user Sign-in method to Password Hash through synchronization from federated with ADFS, although it did not have any impact as users are still authenticating with ADFS succesfully. But now we need to change it back to Federated with ADFS. There is not much documentation on what will be impact or if the trust and claims will be modified if we change it. Any help will be appreciated.
It appears that it is a simple switch.
Note the point about cache issues.
And always good to have backups!
Related
Okta will always gives the previous guest user session when I try to login with another user. Is it possible to end the okta session from azure?
In my iOS application, I introduced Okta as an External Identity by using SAML. All of this is functioning, but when I attempt to log out a guest user, the user will leave Azure, but their Okta session will remain open. As a result, Okta will always gives the previous guest user when I try to login with another user. Is it possible to end the okta session?
Please accept my gratitude for any assistance or advice.
Would suggest reaching out to the Okta Support Team would help here, to see if their engineers and community can take a closer look into your issue.
For reference you can refer to okta documentation related to sign out behavior.
Reference: https://learn.microsoft.com/en-us/answers/questions/1089192/is-it-possible-to-end-the-okta-session-from-azure.html
I'm planning to federate external Identity Providers (Google,Microsoft,GitHub,...) to my applications.
In my applications for security reasons we want MFA to be enabled for every user.
Is there any way to detect if the user authenticated himself using "Google" with MFA?
I understand that federating an external Idp, the user identification responsibility is transferred to the external Idp, so I doubt that what I'm asking would be possible.
Thanks in advance.
OaicStef
P.S.: In my applications, I manage the authentication with Identity Server 4.
The amr claim is what you're looking for but it's optional so it's not for certain that all providers will provide it and if they do they may provide the data in different ways - e.g. one might return ["pwd","otp"] to describe a situation where a password and a one-time code were used and another may just just use "mfa".
The best thing to do would be to experiment and observe what each service does both with and without MFA enabled and adapt as neccessary.
If it's not something you can guarantee then there's also the option of implementing your own MFA features - libs for using TOTP-based authenticator apps or FIDO2/WebAuthn are readily available.
My organization is taking a look at the security of registered applications within Azure Active Directory (AAD) and have concerns around the ability of individuals to add client secrets and certificates for applications that are using the "application permissions" model. I'm working to help narrow the roles of individuals within the organization to restrict this, but this investigation begged the question of what a malicious insider could do if he or she could add a client secret to this application.
I've looked through the 30 Days of Microsoft Graph blog series, which is excellent, but wanted to clarify what else can be done to prevent an insider from gaining access to the permissions this application would allow.
Does the redirect URL itself protect against this kind of scenario, provided the organization retains control of all registered URLs (meaning, for example, that https://localhost isn't registered)? Based on this post under Step 3, I assume the answer is yes but wanted to make sure this is the case.
Is it technically correct to say that without the redirect URL being secured/owned by the organization, a malicious insider who could add client secrets could exploit the permissions granted by the application?
If you are able to add a client secret to an app that already has been granted application permissions to something, then this user can use the new secret to get tokens and access those resources as the app.
Redirect URL is not used with application permissions, only delegated permissions.
This is because there are no redirects in the client credentials grant flow, which is used when acquiring a token with app permissions.
It's just an HTTP request.
So you are correct in your assumption that being able to add a new secret to an app that already has permissions can be a security issue.
There are audit logs though, and I believe adding a secret/certificate is logged.
We uses Azure AD for the SAML Authentication process. Azure is set up as the trust provider using the Federated Metadata that is published by Microsoft here: https://login.microsoftonline.com/common/FederationMetadata/2007-06/FederationMetadata.xml, we configure X509Certificate value in our system to validate the trust so to authenticate the login. We observe the signing certificate changes, that incurs to the change in the certificate value in turns leads to login issues on our system.
Any clue to fix this? Thanks in advance.
You're right.This is changed by Azure. It's called Signing key rollover. It will affect your application indeed.
For security purposes, Azure AD’s signing key rolls on a periodic
basis and, in the case of an emergency, could be rolled over
immediately. Any application that integrates with Azure AD should be
prepared to handle a key rollover event no matter how frequently it
may occur. If it doesn’t, and your application attempts to use an
expired key to verify the signature on a token, the sign-in request
will fail.
How to resolve this:
I understand what you mean and why. But currently, Azure doesn't have notification for this signing key rollover. I also came across this issue. Acutlly, the best resolved method is make my application to handle key rollover automatically by code.Here is some examples.
Otherwise, you need to write scripts to monitor the chagnes if your application does not support automatic rollover .This GitHub repository contains scripts and instructions on how to do this.
I have reported this issue to the Azure PG Team.
Hope this helps！
Currently I'm developing a GAE application in golang that would allow the users to log into the service using OpenID from Google. Each account would be mapped to one Google account obviously. Should I implement captcha for user registration, or does using the OpenID already prevent the service from a bot attack?
Are you accepting any OpenID? Then this is not sufficient protection. Anyone can put up an OpenID site on their own domain, use a script to create a billion accounts, and log in with one of them on your site.
Are you accepting only specific OpenID providers? Then you're not using OpenID as it was meant to be used (and, in fact, expressly the opposite of why it was created). But the answer then would be: do you trust that the OpenID providers have done their own due diligence at the time of account creation to prevent spam accounts?
Regardless, you'll likely find that captcha's a poor solution, and currently all implementations of it are broken (but that's a whole different topic).
First of all, fear of a bot attack is really a preliminary caution. Parsing CSRF tokens (which you should use anyway) and dealing with cookies would already cause enough pain to an attacker. I doubt anyone would trouble himself into setting up very own OpenID provider which is the only way one can do that.
Secondly, App Engine's OpenID Federated Login is the User API feature, not Go runtime's one — you can use any OP with it (Facebook, Yahoo!, Steam... Google). User API provides two modes (configurable via Application Settings): OpenID Federated Login and Google Accounts sign in. Which to pick depends on requirements. If all you need is user's Google account you'd better use the latter, when if it's simple password-less sign in with nearly everything, choose OpenID. From the app's perspective both look identical. Best way to go is OAuth, though.
Getting back on the question, both Google Accounts API and OAuth would make such attacks almost impossible and with OpenID it is a little simpler.
https://developers.google.com/appengine/docs/go/users/overview