I find it very interesting that it took Google such a long time to introduce this service. They had to have a SSO implementation in place for years and with such lucrative prices in the identity market(all products are around $4/user a month) it is low-hanging fruit for Google and seems like obvious step. In addition, many companies are already tight to GSuite and GMail, so I assume another Google Service will be easy to adopt. Would be interesting to see how this will affect Okta and other direct competitors such as Ping Identity, Janrain and Centrify in the long term. I really like their "Google-grade Security" marketing!
This is for companies to manage access for their own employees and other corporate users. If you use G-Suite, then you already have this and can login with your company email account to many external apps without a separate password.
It makes sense that Google is extracting it into a separate product but most companies just stick with whatever their productivity software provider is, like G-Suite or Microsoft Office 365. Many companies also use OneLogin or Okta for extra customization on top of G-Suite/O365.
> It makes sense that Google is extracting it into a separate product but most companies just stick with whatever their productivity software provider is, like G-Suite or Microsoft Office 365.
While available standalone, this is explicitly pitched also as an upgrade (Premium Edition) to what is included with GSuite (which is Cloud Identity Free Edition).
Yes, like I said most companies pick onelogin/okta for that layer on top, which have even more features and customization. It's also further complicated by the fact that GSuite and Office 365 have multiple tiers with more identity features and the Cloud Identity Premium edition seems to be 90% about mobile device management.
We use G Suite and even though it provides identity services, our master is still Active Directory. I'm not in charge of these systems, but I'm wondering how viable it would be to use this as the master source and have AD retrive identity data from it instead.
Wish this had come out a few months back when we rolled out Okta to the entire org and moved away from Google being the main identity provider.
Wonder if it's worth now to roll that back and have Google be the point of entry?
One of the things that I appreciate about Okta is that it sends pretty clear onboarding and 2FA enabling instructions, which I believe G Suite left up to you. Signup into a 2FA-mandated G Suite account was always tricky, having to use recovery codes to get in for the first time. It was terrifying to non-technical users.
The one advantage I can think of, of Google vs Okta/auth0 etc is that most SaaS products seem to give you Google SSO for free, but charge the full enterprise pricing for SAML. e.g. Asana and Slack will not let you SAML from Okta unless you upgrade to their most expensive tier, but Google SSO is always free.
My personal advice: don't move back unless you have a good reason to. If you're a big enough customer to talk directly to a Google sales person, use that as a bargaining chip to get a cheaper offer.
This seems to be a single product of many things announced today. There were 2 Cloud blog posts covering things that happened[0][1].
It seems to all be GSuite/Cloud focused, but there are some big things in there if you use these. Stuff like FedRAMP Rev. 4, Access Transparency reporting, security partnerships, and other stuff.
Frankly I'm surprised its taken google so long to release this. I've used Okta for years and love it. Not only does it make it easy for an org to revoke a users credentials across the board it makes it easier for users to log into every service without remembering another password.
Do I understand correctly that this is basically G-Suite without the apps? Or are there extra features in this (if so, are those coming to G-Suite as well?
I recently redid the identity system for my organisation. Despite using G-Suite as our productivity platform, we ended up going with AzureAD for our identity services for these reasons:
* We needed RADIUS services. No way to get those from Google. It's messy with AzureAD (you need to run AzureAD Domain Services and an NPS server in a VM), but possible.
* A lot of SAML app vendors only seem to know about the existence of (i.e. have built their SAML implementation based around) ADFS (which is close enough to AzureAD). Those either outright didn't work with Google, or involved a messy workaround and a heap of time.
* G-Suite only allows for OU-based access control to SAML apps (unless you want to implement and maintain some code to do this for you, which kind of defeats the point of cloud-based identity IMO). AzureAD can do this by groups or even ad-hoc users.
Still not entirely certain of the link between this and G-Suite. Do I understand correctly that G-Suite includes Cloud Identity (Free edition), but Premium addition is an optional add on to G-Suite? But both Free and Premium versions of Cloud Identity can be used without a G-Suite subscription? So the Free version is basically G-Suite without the productivity Apps? The site doesn't really make it clear what the Free Tier does, and seems to be pushing hard to sign up for the Free trial of premium.
Yes, yes and yes. The marketing sucks and the documentation is a confusing mess, but this is what it looks like:
1) Cloud Identity Free = User accounts, SSO, with Google or external identity provider.
2) Cloud Identity Premium = Advanced user management, device control, compliance, reporting, etc.
3) G-Suite Productivity Apps
4) Google Cloud Platform
G-Suite or GCP include Identity Free Edition, but you can use Identity on its own. And then you can always upgrade it to Premium edition for more control.
I keep wondering why is the pricing of this, auth0 etc so high, is this mostly for the employees and smaller groups? I can't see paying $6/mo/user to manage users for a non-enterprise SaaS offering.
When you have N employees, with people coming in and out all the time, something like this becomes essential. My previous employer used 70+ SaaS apps. Every role needed a different subset of them, ways of restricting access, and to roll them out for onboarding and eliminate access when off boarding. It means that people only need their password to Okta + a single 2FA and that’s it, and corporate rules can be put in place for that login. Even then people forget their password all the time. Imagine the chaos across all 70 SaaS products without something like this!
This exactly. Hard to grasp how much this kind of offering helps until you've had to single handedly do IT for a medium sized (or larger) org that uses a SaaS product for every distinct need.
This is for companies to manage their own employees and other corporate access. OneLogin is a similar product, or you can use G-Suite or Office 365 if you already have that.
Auth0's main product is for managing public user access to your app. AWS Cognito, Google Firebase Auth, Azure AD B2C are all options that are affordable and even free depending on your scale.
*Auth0 and Okta actually do both public app and corporate user management, so it's not as simple when comparing them but you can research their sites for more info.
This is not a tool to for service providers to manage users for an SaaS offering, it's a tool for organizations to manage users for (ideally) the entire suite of SaaS offerings plus devices (including BYOD) used by the organization, across vendors, including internal apps.
Not really. Corporate identity management does much more around fine-grained access, automatic (de)provisioning, syncing data, device management, compliance and reporting, etc.
Of course it can also just authenticate users, but that's a tiny part of the functionality which is why it is so much more expensive.
I think part of the pricing strategy might be to get people to just sign up for Google for Work. They might be getting all these other apps for "free" for the same price as signing up for the authentication.
Otherwise, from what I can tell, it seems a bit high. I might be missing something since it is not my field.
The standalone identity offering is a “Premium Edition” offering that is usable with or without GCP or GSuite but also is an upgrade over the “Free Edition” available to GSuite and GCP admins that allows creating managed identities for users that don't need GCP licenses.
It's so bizarre there must be some mistake. Does this do significantly more than AWS Cognito which free for the first 50k users? https://aws.amazon.com/cognito/
This price point doesn't make sense outside of the niche SaaS offerings that can charge in the thousands per month.
You're seeing Cognito User Pool pricing. Cognito User Pools is basically having AWS host your user / password / details database for an app you're building. It takes care of some details like verifying e-mail addresses / phone numbers and integrates with Cogito Federated Identities, which makes it easy for your app to (for example) allow login via Google, Facebook, or an account they create (which is stored in that user pool).
This Google service looks more comparable to Okta or auth0. That is like if you're a sysadmin at a big company and you want one place where your users can be authenticated, which can then allow access to all of the web apps you use (Dropbox, Salesforce, Gmail, etc.).
EDIT: And to tie them together a little:
If you were building a web app using Cognito, you could likely add a federated identity via Okta, auth0, or this Google service, which would then allow your users to log in directly to your service through that without having to create / manage an account separately.
> This price point doesn't make sense outside of the niche SaaS offerings that can charge in the thousands per month.
It's not for SaaS offerings at all, it's for organizations like employers, and the purpose is to manage identity for employee devices (including BYOD) and multiple SaaS products (ideally, all of the SaaS products used by the org, though obviously not all existing SaaS offering support it yet.)
This is an upgraded version of the identity management (even for users beyond those with GCP licenses) included with GSuite, though it can be used independently of GSuite.
This seems promising. I've been the google superadmin on a few companies and the fight between AD/LDAP and other services and online applications was always hackish. I wonder if the sync is still using this: https://support.google.com/a/answer/106368?hl=en
The benefit was that AD was the authority, so companies still felt "in control". If Cloud Identity is moving authority over to google, that might be an issue, but if it does it well, probably not so much.
The entire LDAP/AD/SSO area is ripe for disruption, because far too many companies are trying to be google and force it all online. Many companies would just be happy with a robust on-premise solution that could replace or augment the others completely.
LDAP/AD and SSO are two different beasts. Everyone uses SAML in my experience and it's a bit clunky but it works and the edge cases are fairly well known.
I don't think it's designed as a competitor to AD, but rather to smooth the AD-cloud user transition, especially as more and more companies buy into SaaS like O365/GApps, etc.
You are right about SAML of course, but my point is how the lines between SSO/SAML etc and AD/LDAP etc are getting blured because companies want them to essentially work as a single unit.
Here are a couple of the interesting alternatives in the arena:
I’ve deployed Auth0 in production before (and quickly glanced through gcloud identity). This seems aimed at larger enterprises (both in terms of features and pricing). Imagine an enterprize trying to deploy ldap or active directory in the cloud age and keeping all accounts in sync with various SaaS.
Auth0 can be used that way but with some work. It really shines when you want to build saas that requires user login. Auth0 is worth every penny (priced by active logins) but I’d be hard pressed to spend 4$ per user if I’m building a consumer saas (but 4$ per employee login is reasonable).
Google Identity is not going to be the right solution for integration with other AD/LDAP stores.
Really big companies will often have multiple AD/LDAP identity stores with enterprise grade provisioning systems (Sailpoint, Oracle Identity Manager) to keep accounts in sync.
This offering from Google is meant as a replacement for AD/Exchange(obviously) for companies that are mid-small. It also offers provisioning to other apps but only those that support SAML Just-In-Time provisioning. I did not immediately see a way to add custom apps to this (for provisioning), so might be limited to just the OOTB apps they provide (List: https://support.google.com/cloudidentity/topic/7661972)
Auth0 today offers SAML integrations and if the target system supports JIT Provisioning, it will work the same as google.
And just to clarify, Google's offering is 100% meant for internal users (employees, anyone that you'd give a Google Apps account to)
Yes. I don't see a large scenario where a company isn't already using G-Suite or Office 365 and the higher tiers include all the compliance and management features. Usually if they need more customization then they use OneLogin or Okta on top, or build their own system.
GSuite provides less features for identity (it bundles what is now described as the Free Edition of Cloud Identity, while the standalone/add-on product is the Premium Edition.)
You can "login with Google" on third party sites, but it involves an asking permission screen. The seamless SSO experience only works on Google's own properties.
If any google developers are out there - it would be great to be able to try this service out without having to type in a ton of information to get started - i just want to log in and see how it works - how it compares to IAM, auth0, etc.
I don't see Gitlab explicitly listed as a supported service, but wonder if that would be supported or require google or gitlab to make the integration happen. (This is on a GL EE instance we manage).
And what about public-facing web apps developed in-house? Can we add SAML integrations that would work with this for employee access?
These are probably basic questions, but I couldn't seem to find the details on the site.
No extra products needed if they're already using one of those supported providers. OpenID Connect makes things much simpler than traditional SAML unless you need all the extra enterprise provisioning features.
just last week i worked on integrating google4business and aws login. in the end of the day, i spend half of a day and had never made this work.
one of the steps of their's guide required to create oauth application, assign it some specific scopes and use their api browser to submit some jsons to create some custom attributes for the company users. i spend the whole time figuring out how their oauth works and why their api endpoint authentication never worked for me.
the whole experience left me with a feel of extreme complexity and I feel completely lost in oauth and SAML.
i just checked the guides and it seems there are no changes to the aws integration guide - integration mechanism for aws is still the same :(
Anyone else notice that they're now rolling out Product Sans / Google Sans on new branding pages (News Initiative, here, etc.)?
I personally like it a lot, but I wish I could use it (I guess I can always use Futura and tinker a bit).
Beyond Corp isn't a product, it's a security model where you treat everything as a publically accessible resource without any special intranets, VPNs or other gateways.
Employees use your apps the same way your customers do. Internal apps would obviously be limited to company accounts, but this simplifies security and deployment by reusing the same infrastructure and oversight across both public and private apps.
Disclaimer: I work at ScaleFT - we offer BeyondCorp-like access controls as a service for servers (SSH & RDP) and internal web apps.
Exactly right... BeyondCorp is more of a reference architecture than a product. Google's own internal implementation is what the research papers focus on, but we're seeing more companies adopt similar models by shifting access controls to the application layer, where a request can be independently authenticated (corporate IdP) and authorized (RBAC, policies) against more dynamic conditions - such as the security posture of the user's device.
The Identity piece is a critical component to the system as the user system of record, but really just one of the inputs in a BeyondCorp-like environment.
Sure. It's not a BeyondCorp product but a way to implement the BeyondCorp security model.
These are all separate pieces of architecture:
1) Corporate user database with access rights and permissions. This can be Google's G-Suite if you're already using it or this new Cloud Identity product.
2) Access to external corporate apps (like Salesforce) using OpenID or SAML connections with the above mentioned user system.
3) Access to internal or custom-built corporate apps (like a sales dashboard). You can use the APIs and build it into your app or use the IAP product to act as a smart firewall that will handle the authentication for you and just give your app a simple HTTP header with the user's name/email so you don't need to build any user auth in the app itself.
Given the recently revealed consequences of people using a major third party (Facebook) for user authentication is this really going in the right direction?
I do understand that, but you are outsourcing a linchpin of your infrastructure to a third party. Are these identities completely disjoint with regular google ones or are they comingled (i.e. do you need two different browsers to read your work gmail and your personal gmail?)
I think he/she gets it. It is possible to run your enterprise without using Google software that forces users to pour even more of their data into Google's grasp.
So I think the OP was saying that it would be desirable for those enterprises to allow employees an alternative, for those who do not wish to share even more with Google.
It's not their data, it's the company's data. They don't have access to the services with their personal accounts, only their corporate ones so any data that they pour in is professional work, which belongs to the company. Why would I possibly care that google is mining my company's AD structure or which documents I access in the corporate network? It's the company's problem.
Actually, that example doesn't sound at all insane to me. What if Workday then sells the information that I'm sick a lot to future prospective employers or to health insurers? The employer should have a duty to adequately protect that information. It's not just "their" data.
I don’t know about the US law on confidential employee data, but in some countries selling data like that would be an open and shut lawsuit (against both Google and the employer).
You're confusing different types of data. Data that belongs to the employer, and personal data about the employee which is protected as personal and private as a matter of course, even within the enterprise context.
The company personnel directory is usually considered confidential. Why give it to Google, a company very well equipped to tie those data to personal identities?
> Why give it to Google, a company very well equipped to tie those data to personal identities?
Companies already frequently outsource that list with full personal identities to payroll/benefits providers, among others. Sharing it with someone who might potentially tie it back to personal identity is not, comparatively, a big deal.
You're saying that having Google manage the identities will not provide Google with all the data and perhaps even make them trackable by Google?
What makes you think so?
Cloud identity doesn't appear to be something that you deploy in your network and that is completely isolated from the Google cloud. Quite the contrary.
Whatever google can or cannot do with the data depends on their ToS but that is a problem for the company that contracts them to deal with as it's their data; not the users.
Most importantly, virtually all PaaS and SaaS solutions (office365 being the most well-known) already operate like that; on-prem services are getting pretty scarce nowadays on the enterprise world.
Edit: Spelling