Cloud Identity
cloud.google.com
cloud.google.com
Edit: Spelling
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.
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).
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.
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.
[0] https://cloudplatform.googleblog.com/2018/03/introducing-new...
[1] https://cloudplatform.googleblog.com/2018/03/expanding-our-G...
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.
There's a free tier which is already included in G-Suite or Google Cloud and the premium tier which has more control: https://support.google.com/cloudidentity/answer/7319251
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.
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.
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.
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.
Otherwise, from what I can tell, it seems a bit high. I might be missing something since it is not my field.
The current name for this product is G Suite.
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.
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.
Don't get me started on radius...
Is this actually a competitor to AD?
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:
https://www.univention.com/products/ucs/
One of my planned side projects is to test each of these.
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).
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)
Edit: BTW, I see this can be set up for Github Business. Does github.com not support SAML?
https://aws.amazon.com/blogs/security/how-to-set-up-federate...
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.
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 :(
Unfortunately, poor mobile usability on their dev sites is very common for Google, which is something I could never understand
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.
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.
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.
Always provide an alternative.
I'm pretty sure this is aimed at enterprise applications.
I wouldn't be surprised if it's illegal in Europe if a company forces this upon its employees.
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.
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.
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.
I hope you realize the insanity of the following exchange:
"Bob, you should enter your sick leave in Workday."
"But I don't want that company know about my sick days. Can I use something different instead?"
"No, you may not. This is the software all employees use."
"But Workday might sell my data!"
"...alright, how about you fill in this Excel sheet."
"No, Microsoft might be spying on me."
"You're fired."
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.