I do not get the idea of using 2FA with SSO.
Is not the whole idea of SSO, that you do not have to log a second time for each application and with 2FA that is exactly the case.
Or is it like no SSO for the sake of security?
Nope
2fa says 'when you have to authentication you have to have more than just a password'
SSO means - once you have authenticated on to a central ID system, maybe using 2fa, maybe not , you do not have to authenticate to the individual apps
2 quite different things
It is possible for an SSO system to be configured to demand reauthentication or just the second factor in some circumstances. For example if the SSO system sees you are coming from an IP address its never seen before, of if you are trying to access a particularly sensitive app.
An SSO system is always a balance between end-user convenience and IT department paranoia
Related
We want to use SSO for a group of apps (this will include GitLab, probably Drupal and a bunch of small apps I will write in Symfony for various tasks). We would like to currently use Google accounts to authenticate all apps, but because there are limits (I know you can increase them) on how many apps you can have and Google sometimes change what features are free, it would be good to have the option of using our own login down the track if needed.
I have used SimpleSAMLphp in the past with GitLab (using a database to store credentials) and it worked well. Is there a way that I can use the Google Auth as an IDP and have SimpleSAMLphp record the email address to link the accounts etc and allow me to add things like groups etc in to send down to the app when a login happens? I would put a password field in the login table in the database as well so that if we decide to move away from Google we can generate random passwords and continue without too many issues.
The information I find online is for using SimpleSAMLphp as the IDP for gsuite etc (we will be using general Google accounts, not ones in gsuite) and not the other way around. I also couldn't see any Authentication Modules for Google authentication. Are there any tutorials or instructions anywhere on this?
You can accomplish what you are asking fairly easily. Instead of integrating your SPs with Google directly, integrate them with an SSP idP you control, then set up your authentication page (i.e. the page redirected to by your authsource module) to be an SP for Google. Here's what that looks like:
vendor sp -> your SSP idP -> your login app -> your SSP SP -> google idP
This way you end up with only a single Google integration configured for all your vendor integrations. There are numerous benefits to this approach:
You aren't affected by # of integration constraints imposed by google
Since your vendor SP integrations are controlled on your own server, you can easily move to a different cloud-based idP for authentication in the future without having to re-integrate all your SPs
You can easily give your users alternate sign-in choices if you want.
You aren't constrained to SAML or protocols supported by Google. Many vendors still use proprietary token based authentication. These can easily be supported with this setup.
Happy to help with implementation details if you need it.
I am currently developing a RESTful API server, and I am choosing between using ID and password or using a token to authenticate a user.
Let me, explain my situation first. I need to include static authentication information to my library to communicate between a client and my server or provide it to a partnership company to communicate between their server and my server. And when I was researching other services which are in a similar situation as us, they are using token now (for example, Bugfender is using a token to specify a user).
However, what I think is that using ID and PW and using the token are the same or using ID and PW is better because there are two factors to compare it is correct or incorrect.
Is there any reason why other services are using a token?
Which one is better as a security perspective or is there a better way to do this?
I think, if you are going go use on your client fixed username/password, or some fixed token, then the level of the security is the same.
Username and password is not considered as multi-factor authentication. Multi factor means that you are authenticating someone by more than one of the factors:
What you know. This can be the combination of username and password, or some special token.
What you have. Might be some hardware that generates an additional one time password - Google authenticator app on your telephone, or SMS with OTP received with some time expiration.
What you are. This is for example your fingerprint or retina of the eye.
Where you are. This can be the IP address of the origin if it is applicable for your setup.
How you behave. What is your normal way of using the service.
etc.
Maybe not needed to mention that both - the token and the username/password combination have to be carried in an encrypted requests (I believe you are using HTTPS). Otherwise the client's identity can be stolen.
How are you going to provide the credentials to your client library? I thnk this is the most tricky part. If those credentials are saved as a configuration (or worse hard coded) on their server, is that storage secure enough? Who is going to have access to it. Can you avoid it?
What would happen if your partner company realize that the username/password is compromised? Can they change it easily themselves? Or how fast you can revoke the permissions of stolen credentials?
My advice is also to keep audit logs on your server, recording the activity of the client requests. Remember also the GDPR if you work with Europe servers, check for similar regulations in your country based on what you are going to audit log.
In case the credentials (ID and password) and the token are being transferred the same way (say: by a header in a REST request) over a TLS secured channel, the only difference lies in the entropy of the password VS entropy of the token. Since it is something for you to decide in both cases, there is no real difference from the security perspective.
NOTE: I don't count the ID as a secret, as it usually is something far easier to guess than a secret should be.
I'd go for a solution that is easier to implement and manage.
IMHO this would be HTTP basic authentication, as you usually get full support from your framework/web server with little danger of making security mistakes in authentication logic. You know, friends don't let friends write their own auth. ;)
Related to Accessing Third Party Apps After Creating A Session Via API Token and to AWS API credentials with OneLogin SAML and MFA
Since AWS assumeRoleWithSAML temporary security credentials are only valid for one hour and we have a few different roles to assume it would be very annoying for the user to enter the username/password everytime he needs to switch the role or get new credentials because of the short validity. It's totally odd to the web base OneLogin usage, where he is logged in once for the whole day or even week (depending on the policy).
I know how to get a session via API. At least this would reduce the times the user needs to enters username/password to two times. One time in the web, one time on the CLI.
But is there any way to use this session token to generate a SAML assertion via API with this session token instead of submitting username/password to the API endpoint?
I don't want so store the users credentials locally for this. And with MFA enabled this wouldn't work in a seamless way.
While being able to generate a SAML assertion for any user (without the need for MFA and a user/pass) seems like a good workaround, this is unfortunately fraught with security perils.
An API that bypasses the usual authentication effectively gives that endpoint the ability to assume any user in AWS. The "assume user" privilege is locked down pretty tightly in OneLogin, and is not the sort of thing that's given out lightly.
Basically, an API to do this seems dangerous from a security perspective. This might be something we'd consider as part of an oAuth flow (or OpenID Connect resource endpoint) but that'll take some more thinking on our part before we'd implement it.
The only compromise solution I can think of that could be implemented today would be to temporarily cache the users' credentials for a longer period of time in your code. This way they could be reused to generate new SAML assertions for a longer period of time, but would effectively be thrown away after (say) eight hours.
This wouldn't allow for MFA on an app policy, but we are building out the ability to request and verify MFA via API (coming soon) so you could implement MFA in your app (independent of any app policy) once this becomes available.
Obviously the ideal solution would be for AWS to let users' configure the session length, but so far they've been unwilling to allow this.
I am researching different Single Sign On options. It seems to me that SAML while is a great solution if we look at 3rd party vendors it is somewhat out of our price range. We are also looking at implementing our own solution... but, some of the services we want to use - just to enable SAML logins they want to charge. If I know all of my user's credentials what is the security risk/downside of just doing an HTTP POST with the credentials to these different services? Some of the SSO providers do this when SAML is not enabled as well.
Using SAML would remove the need for users and Service Providers to deal with password issues like reset, expiry, recovery, rotation etc. completely, aside from managing the synchronization process that now needs to happen between IDP and SPs.
In addition to that there's the the amount of brittle, costly and awkward reverse engineering of SP login webpages that needs to be done and maintained(!) by any IDP that operates a password vaulting system (which is what you describe).
Also, introducing an SSO system allows you to concentrate user authentication efforts and improvements in one place only, making it simpler to introduce strong or second factor authentication for all services at once, without requiring support for that by each SP.
Last but not least: password vaulting systems still involve passwords that are distributed over different systems/SPs and that cannot be (completely) hidden from the user. That makes it hard or impossible to ensure that access to all systems is turned off at once e.g. when a user leaves the organization.
Few sites I've come across using either Google, Facebook or Twitter connect for login. Still they are asking for new password creation.
Ex: http://setapp.me/
Why user need to setup another password when the user is using OpenID/Facebook/Twitter connect?
One need I can think of: if the user disconnects the app from any of the above OAuth/OpenId connect services providers (Google/FB/Twitter/...), then as an alternative way for the user to login - as a best practice.
What they're doing is an incremental step towards federation, but not what I'd describe as a best practice. For apps that aren't ready to fully embrace relying on another service for identity it is still sometimes helpful to connect with identity providers to speed up the sign-up process. In other words, just as a mechanism for pre-populating the signup form.
However, if using it for sign-on, then having a local password is one more potential vulnerability. The reality is the vast majority of users just re-use passwords across sites. That password is only as secure as the weakest application that stores it. If one app is compromised and email & passwords recovered, attackers know that a good percentage of those are valid logins elsewhere.
Best thing to do when federating with Google/Facebook/etc is to not ask the user for their password at all. Trust the major identity providers to keep account information & credentials secure rather than take on that responsibility yourself and deal with the fallout if your app is compromised.
Lots of good reading here if you're up for it: https://docs.google.com/a/google.com/document/pub?id=1O7jyQLb7dW6EnJrFsWZDyh0Yq0aFJU5UJ4i5QzYlTjU#h.moajj1qnb85l