We have enabled SSO for our Google Apps Domain. When users try to access "http://mail.google.com/a/domainname.com" they get redirected to the custom SSO Sign in page url. But when url http://google.com/a/domainame.com is accessed users are able to login to google apps users hub without being redirected to SSO sign in page url. As per my understanding, this kind of login should be only enabled for administrator of domain. Why is it happening for normal users of our domain.
How can we redirect http://google.com/a/domainname.com" url to custom sso sign in page. Please help. Thanks in advance.
You can't block people from logging into Google through 'local' credentials, if they know them: they need this for access via mobile devices, where you can't be redirected to a web page for SAML SSO, for example.
The normal solution is to change the password to something the user doesn't know.
Further, if you force 2-factor authentication for your users, this means a user can have one-time passwords for their mobile devices and still have an account password they don't know.
The www.google.com/a/yourdomain.com url points to google cpanel, which can never, ever be restricted through custom SSO, as this is your only recourse to disable SSO. If anything goes wrong, you need to hit that url to turn off SSO or change SSO settings.
If you wish to restrict access to cpanel, please look into organizations restrictions / superuser privileges; you can restrict cpanel superadmins to only one or two trusted admins.
If you wish to have only a single admin account with access to cpanel, but want to give some cpanel features to regular users, check out some third party apps in the google marketplace; gPanel is especially good as it gives you fine grained control over who can access what. Couple that with SSO, and you get a complete logging / monitoring / access control solution.
Related
I have a REST service that my mobile app uses to authenticate when the users click on the Facebook or Google icons.
The service accepts the user's id from the provider and checks if it exists on the database and then issues the access_token to be used for the other methods.
The problem is that I just thought that it could be pretty easy for someone to intercept the calls and discover which service authenticates and what the user id is and then call it with to get a token.
How can I avoid this?
I think you just need to separate the authentication and authorization functions. You can let Google (Google Sign-In) handle authentication. If you follow the API they will securely authenticate the user and send you the token which you can validate.
Once you know who they are for sure, your site can safely authorize that user approriately. For example, they might be an existing user, need to make an account, be an administrator. You can make those authorizations on your site based on the user authenticated by Google (in my example).
Twitter, Facebook and others do the same. Also see OpenID Connect.
Is there a way of passing username/ password to Google Apps IDP and get a response as to whether a username/ password pair is correct?
I know I can use OAuth for authorization and access user data but note that I want to check if his credentials itself are valid. OAuth for sure will not work for me. I need a way to directly query Google Apps' IDP particularly not to use it and access something else.
I wish to use this to customize the Google's standard login page itself. OAuth doesn't allow me to do that.
Short answer: no.
Google actively tries to prevent the scenario that you describe because it would mean that Google users hand over their Google credentials to your application, aka. phishing.
That precludes branding of the Google login pages as well since it would make it harder for users to verify that they actually type in their credentials on a login page provided by Google.
As said in the other answer, Google Signin with OpenID Connect (built on top of OAuth 2.0) is the standardized way to offer users login to your application with their Google account.
Google (Apps) accounts can be used as an OpenID identity provider. By implementing your app as as a relying party, you could authenticate your users based on their Google accounts. Much like stackoverlow Google login: http://code.google.com/googleapps/domain/sso/openid_reference_implementation.html
With SAML SSO, Google acts as a relying party. While its possible to use provisioning API and clientLogin, this is not supported and is possibly against Google Apps ToS.
When you visit some websites, you can register and sign in as an authenticated member of some other organization (Google, Yahoo, etc).
What's to stop a malicious website from simply presenting a logon screen that purports to authenticate against those other sites, but is in actuality simply gathering usernames and passwords?
Could someone explain how such spoofing is prevented?
You are referring to the OAuth protocol.
Regarding what you ask, notice that you don't insert your credentials on the site you want to login but in a specific page of the provider offering OAuth authentication, you can't simply give to the user a fake page like you describe, or well... you could, but people familiar with that kind of authentication will notice (e.g. it asks me to login to google in a non-google hosted site?).
I am trying to login users via the 500 PX API,
http://developers.500px.com/docs/oauth-request
It seems like the only way to do this is via a webview, have the user authenticate, and once they login to 500px, they will be rerouted back to my app with the access token.
How can I do this without a web view? I want ti implement 2 text fields, one for username and one for password, and then login the user.
Thanks in advance!
The whole premise behind the OAuth pattern is that 3rd party developers should never be trusted with the user's username and password. Instead they are redirected to the service's login portal, which the user knows and trusts, where they enter in their username and password, give permission to the untrusted third party application, and then are redirected back to the untrusted application with an authorization key and secret, which the third party application can then use to access the service on the user's behalf.
User's are used to this pattern, they trust it. By breaking this pattern you are breaking convention and web savvy users are less likely to use your application.
I am creating a SaaS that will allow users to interact with it via their web applications. I would like to create a CAS type login mimicking Facebook connect so when you click the 'Login' button on the users website it will popup a window for you to login with my SaaS credentials.
I do not want the SaaS users site to be able to access the users login credentials so this is why I thought of CAS. However, it doesn't look like Facebook Connect redirects to the CAS server. It looks like they just popup a window to the facebook login then create a cookie once the user successfully logs into facebook. How then does the Facebook Connected site access that cookie?
I am wanting to basically be able to keep the end user on the current website without being redirected to my login application. I would like to mimic what facebook does with just popping up a little window and have them login then refresh the page after they login but I am not sure how to go about this.
Any ideas?
Facebook uses a third party cookie: they set a cookie on your domain that you can access to get the necessary credentials.
EDIT: the easiest example would be to look at PHP's setcookie function. Notice that there is a domain parameter. If you change the domain to match the domain of the actual website that initiated the authentication action then you'll be able to set a third-party cookie.
Note that on IE there are certain headers the domain that initiated the authentication action needs to set to allow your third-party cookie to be set. See http://www.spamcollect.com/archives/33 for a short writeup of how that works.
If you are working in a different language you'll need to use whatever cookie management functions they offer.
Another option may be to do this with CAS programmatically using the REST client.
https://wiki.jasig.org/display/CASUM/RESTful+API
In this way you could take the users details and login to CAS without being redirected.
Facebook uses Cross Domain communication which is what I will be using.