I've implemented the BetterAuthorizationSample for the hope that the user would not be bombarded with the authentication dialog box for privilege operations. The implementation mostly works, however it does require the user to authenticate once. I want to disable authentication all together. Is this possible with the BetterAuthorizationSample?
Any suggestions?
Thanks.
No.
This completely defeats the purpose of authorization. If there was any way for applications to perform privileged operations without the user's express consent, then malicious programs would be free to do whatever they wish.
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
Right now I've only requested the permissions required for a user to successfully authenticate into the SaaS application. These are delegated permissions.
I'm now wondering how to handle permissions for a new daemon integration, which will request different data from Graph and require application permissions. So far I see these alternatives:
I create a new application, representing the integration, and if the customer wants to enable this feature they go through the admin consent flow and grant the required application permissions.
I encumber the main app with the 'optional permissions' and tell the customers that if they don't use this particular feature then they can revoke this and that permission.
Are there more alternatives? How are others handling this situation?
I foresee more daemons, requiring different permissions, in the future which makes alternative 1) seem quite unattractive. On the other hand, I can envision push back from AD admins everywhere if I go down route 2) and ask for all kinds of permissions that aren't applicable to that organizations feature set.
Best practices would dictate you have a separate app registration for each application/daemon. That being said, if you don't want to, you could do something between your two options, make a second app registration for all the daemons, and make a simple SPA just to log in to give consent to that app registration, which is separate from the saas app registration.
I would definitely avoid option 2 on your list though, because then the saas application would technically be able to access all the same things your daemon permissions have which can be a big security risk.
So i'm tasked with implementing SSO for our Windows application. Currently, after a user logs into the machine, he or she has to re-log in to our app when he or she loads the application. The application validates the user by querying a LDAP server.
What we're looking to have is for the user to automatically be logged into the app when they click on it. My understanding is that the LDAP authentication must still happen, but Im not exactly sure what the workflow would be, and how exactly we can validate a user without requiring them to re-enter a username / password. Note that this is not a web application so I can't use tools like SAML or OAuth (unless i'm mistaken about this too..?)
So my specific question is as follows:
Is it possible to use LDAP for SSO, and if so, how? Is it possible for me to authenticate a user with just his or her username, or is a password also required?
Any guidance would be appreciated, and am happy to provide further clarification if needed.
First of all, LDAP is a protocol, which you use to communicate with databases that implement this protocol.
So LDAP databases (commonly called directories) are ... databases and so do not provide SSO functionality.
To deploy a SSO solution, you need a SSO service. All your applications will have to be "compliant" with this service in a way or another.
The only way I can think of to make a "Windows SSO" without adding a third party application is that the applications can retrieve NTLM informations in requests made by the client and uses the user data to identify him. (but in term of security, I let you judge what you think about it ;) ) . See this php example
Some LDAP implementations, including OpenLDAP, provide some level of support the Generic Security Service Application Program Interface (GSSAPI) or SPNEGO (a specific GSSAPI implementation)
Although not trivial, it is possible to perform SSO from a "browser" that supports GSSAPI. AFIK, IE, Firefox, Safari and Chrome all provide some level of support for GSSAPI although each browser requires specific configuration (typically whitelisting of Servers).
There are many SSO Products that implement these features in a "probably" more secure and easier process than doing it yourself.
There are many known vulnerabilities details that have been exploited with GSAPPI/SPNEGO typically due to implementation issues.
We're trying to evaluate a solution to implement "true" SSO for multiple (already existing) web solutions. True SSO here means to login on any service, and be authenticated on all, without further actions from the user.
All of the applications we're going to use support OpenID and/or have plugins that allow OpenID, so this seems like something worth looking into. However, as I understand OpenID, the users would still be required to enter their OpenID credentials in each service.
Is there a sane way to implement SSO with automatic login once the OpenID provider has authenticated the user?
In an earlier project, we hacked up the PHP session data in the login procedures of two applications (both running on the same domain and server) so a login in the first application creates the session data for the other application as well. However, this is a very hacky solution and is prone to break when either application is updated, so we're trying to avoid it this time.
Are there any other SSO solutions that we could look into?
i am assuming that you have the control on the SSO implementation
there are some things you can do to make sure that once the user has been recognized by the SSO application, he will virtually automatically be logged in to your other applications
in your SSO application, create a whitelist of service providers. authentication request from those websites will be automatically approved. thus, user won't be asked to approve the request manually
in your application, set the return_to parameter as the page the user is intending to immediately open. don't simply set the return_to to that application homepage
by the way, the most standard openid implementation accepts any url. however, if you want to use the sso in a controlled environment, you can set the service provider to have a whitelist of trusted identity providers. after all, it's the service provider which initiated openid authentication.
Yes, there is a means to do this. Run an Application Server, Node Based, and register cross-domain techniques to offer cookie-credentialed (backed up by site-handshakes as each new user arrives, to scale better and minimize resource expenditure per-session).
I am working on such a beast right now, and I'm 5/6th done.
I have taken care of several annoying variables up front- including the means to assure unique user logon- and I've taken a stand on other issues- one just can't get everything done in one system. However, one can have a true SSO if one is willing to pull out some stops. It is YOUR stops which will define your solution. If you have not accurately portrayed your limitations then there isn't a solution which can be offered for implementation here, and the nature of your problem is ENTIRELY implementation- not theory. In theory you have 4-5 different options. In practice you will find your answers.
I have a PHP application that is successfully authenticating against a CAS server. One of the features supported by the application is impersonation; a user with the appropriate privileges can impersonate another of the application. Generally, this isn't a problem because the app itself can keep track of who the user is impersonating and manage privileges (which are based on username).
A new requirement has come up, though, that requires the original app to include, via an iframe, content from a second PHP app that is also CAS-enabled. Somehow, I need for the second app to know whether impersonation is happening in the first. I don't want to pass usernames around for security reasons, so I'm wondering whether I can offload the responsibility for handling impersonation to the CAS server which is shared by both apps.
Thanks.
I realise this is a very old question, however, CAS as of v5.1 does support impersonation. It's referred to as surrogate authentication:
https://apereo.github.io/cas/5.1.x/installation/Surrogate-Authentication.html
The more we considered this and tried to get something worked out, it seemed more and more likely that this just isn't available in CAS and perhaps shouldn't be. If we accept that CAS's sole purpose is to identify a user and ensure that the user is who they say they are, then it doesn't make much sense to be someone else.
This is just me speculating about the underlying justification, but I feel pretty comfortable saying that CAS doesn't offer impersonation functionality.