We currently host >50 client sites within cPanel which we manage via SFTP using separate account username + passwords for each. It would be beneficial for us to switch to a key-based login and disable passwords.
How would you go about doing this so you could login in to any one of the client sites? The clients themselves never have access which is limited to our in-house developers.
Would it be a bad idea to share a single key between all of them?
Yes, it's very bad idea to use same key for your all 50 sites, I will suggest you create separate key for your all sites and use that to login instead of password.
Related
This question already has an answer here:
Automatic Login from one web site to Moodle web site?
(1 answer)
Closed last year.
I have an user details stored in my web site database and Moodle database. I logged my website with that credentials , Moodle also auto login with that credentials is there any way? Or any Code is available?
If you're handling credentials correctly (and Moodle does), you DO NOT STORE THE ACTUAL PASSWORD! Instead, you store a salted hash of the password.
When someone tries to log in, you salt and hash the attempted password using the same salt and hashing algorithm. This will give you the same result as the value in the database, and so instead of comparing passwords directly you now compare hash values. In this way your users are protected from having their passwords leaked if someone breaches your application.
If you're not doing it this way on your own site, you're doing it WRONG and need to fix it ASAP. This is big deal!
Here's the thing: the two web sites aren't necessarily using the same hashing algorithm, and certainly aren't using the same salt. Therefore the user credentials you have saved for your web site are NOT the same credentials saved in Moodle, even if all the users have the same password.
But what you're really asking about is SSO (single-sign-on). There are (safer!) ways to support this. SAML, CAS, Shibboleth, and OAuth come to mind, and Moodle definitely supports these. You can also have Shared (as opposed to Single) Sign-On, where both your app and Moodle use a third party such as AD or LDAP for identity verification, so the username/password credentials are the same but you still have to sign into both applications separately.
Unfortunately, you will need to build this into your own app, as well, and perhaps even add an additional authentication portal server to your organization to act as the trusted intermediary between each of these applications. There are a number or products you can use, including some that are open source or may already be included with other licensing, so you don't have to start from scratch or necessarily make an expensive purchase here.
The good news here is these products generally also put you into a good position to start supporting Multi-Factor Authentication, which is also an important feature to provide.
Suppose I have a simple node backend application which when ran needs to connect to a specific GSuite instance, query some things (users, groups, etc.) and then close and not run again until needed, which can mean either a very long time or a few seconds. From what I gathered from Google's documentation there may be multiple ways of doing this, including having an OAuth client and follow the whole flow in setting it up, managing token lifecycle, etc.
However I do NOT want to go with this option for now for various reasons and I am wondering if there is any way of getting access by means of an API Key / secret, like many other 3rd party services allow nowadays. Simply put I would like to generate a key pair somewhere on GSuite, no idea where, and use those keys for auth instead of OAuth, something Google suggests is possible, both on the GSuite Admin app (with a broken link that leads nowhere - not surprising) and on GCloud API and Credentials subpage where you setup credentials (however there it says that API Keys can only be used for very limited resources, none of them having anything to do with GSuite).
I think your best option is to see if what you want to do can be done by a service account. You can create a service account, grant administrator privileges to it in GSuite, enable some APIs, and then that account can do a lot of things without using OAuth directly. The credentials for the service account can then be provided to your application as a json key file, which it can use to authenticate to GSuite. You can also grant service accounts permissions to specific objects like files in Drive, but it doesn't sound like that would be sufficient to your needs.
A guide that may be helpful in the details of how to do this is https://m.fin.com/2017/10/04/navigating-the-google-suite-directory-api/
We have a application running already lets say a.example.com, now we are planning to add one more application as b.example.com. We are already storing user session of a.example.com in Azure Redis cache. Is there a simple way to provide SSO between my two sites, by utilizing the existing Redis session store.
Note : please dont suggest using identity framework, as I dont want to have a separate server, to do authentication. Correct me If I was wrong here guys.
Thanks in Advance
Ganesan S
I will first say what could be a solution, then give what my work has done since we have multiple sights that all deal with their own sessions, but are all linked.
When you create a session for a.example.com, could you also create b.example.com as well and have both put in the Redis store? Then when a person signs out you can find the session for both sites based on the user and delete both at once.
Another option could be to have 1 session that both sites look for. That way each user only has 1 session, so there is only 1 to create and 1 to destroy. You could set up the domain to be by example.com unless there are other sites that should not see that domain.
We use a Service Provider that creates a sign in hub that all of our sites point to. Then each site gets its own session that has a domain over everything. Then when someone logs out the server will delete all sessions at once and call logout for the user at the service provider. In your case you could treat the Redis session store as a sort of Service provider storing the sessions for the users that your websites look at for user validation?
I have a setup with 4 LDAP servers, and I'd like to use the same credentials to authenticate and administrate all of them.
What I had in mind was to use one of the servers to host the credentials, and then setup a referral in the other servers to the server hosting the credentials.
I've done some tests and I didn't managed to authenticate on one of the servers using the "referred" credentials. I believe this is normal but I'd like to be sure I didn't miss anything.
Lastly, if referral do not work, is syncrepl a good candidate to achieve what I'm trying to do ?
Thanks for your help.
Michael
When an application receives an LDAP referral and follows it, it opens a new connection which needs to be authenticated. In other words, if you need to authenticate against all directories, you need to have the credentials in all directories. Replication is the way to make sure the data is identical on all directories.
Here's something similar to this question on general SSO best-practices. What is the best approach for dealing with a disabled or for-whatever-reason-unreachable central identity provider. If your website allows users to login with their centrally-stored credentials, and the central service is not working or unreachable do you:
Allow users to re-enter their credentials on the local site, so that they can use the native login facility of the web application (or content management system or whatever)
Allow users to request another secondary set of credentials that they can use on the web application itself (i.e., a separate password they can use when the IDP is down) [NOTE: obviously this defeats the 'single credentials' goal just tossing out all ideas].
Allow the users to login using any of several various maintainers of the same credentials (by giving them multiple links to multiple providers, and then trying each one of them until one of them actually connects and works)
For probably apparent reasons, none of these solutions above seem attractive, so feel free to put these on the "worst practices" list while you answer with the best alternative approach.
I'd think the best way would be to have decentralized SSO, as is implemented in Open ID. If each account can have many providers, then if one provider goes down, you can fail over to another.
On the other hand, if centralized SSO is required. The only thing that I can think of would be to have the central authority generate a cryptographic certificate for each user. If the service has a fresh copy of the certificate revocation list and a cached copy of the central authority's public key, it can validate certificates even if the central authority is unavailable. Unfortunately, this method would probably suffer from usability issues as users would need to both keep a copy of their certificate handy and know what you're talking about when you ask for it.