Cloud Identity(cloud.google.com)
cloud.google.com
Cloud Identity
https://cloud.google.com/identity/
98 comments
> 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).
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.
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.
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.
This is an extra service, the same way you can use Onelogin or Okta on top of G-Suite to do federation and syncing.
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
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
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.
https://support.google.com/cloudidentity/answer/7431902
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.
https://support.google.com/cloudidentity/answer/7431902
For the uninformed, how is this different to implementing Google Oauth?
Please don't force your users to identify themselves to Google or Facebook.
Always provide an alternative.
Always provide an alternative.
> users
I'm pretty sure this is aimed at enterprise applications.
I'm pretty sure this is aimed at enterprise applications.
Forcing your employees to be tracked by Google is even worse. They can hardly opt out.
I wouldn't be surprised if it's illegal in Europe if a company forces this upon its employees.
I wouldn't be surprised if it's illegal in Europe if a company forces this upon its employees.
You don't get it: this is enterprise software. People would login (and only have access) with their enteprise accounts, not their personal ones.
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.
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.
Why does it matter whether they want to share their work data with Google? It's their company's decision. Their company owns the data.
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?"
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?"
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).
Your example makes my point for me. Thank you.
Here's the rest of the exchange:
"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."
"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."
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.
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.
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.
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.
They're likely already using google apps
This looks like an alternative to the typical Active Directory/Exchange setup that many large corporations run.
This is about enterprises managing user accounts.
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.
Bad timing
I think this is the result of the Bitium acquisition.
How does this compare to auth0 (https://auth0.com/). Is this a direct competitor?
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).
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)
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)
Didn't Google already have an SSO solution? I'm using it in GSuite at our company. Or was it restricted to only GSuite?
Edit: BTW, I see this can be set up for Github Business. Does github.com not support SAML?
Edit: BTW, I see this can be set up for Github Business. Does github.com not support SAML?
Yes, G-Suite/Google Cloud all use the same system. This is just extracted for companies to use without G-Suite or Google Cloud.
Doesn't that mean it's cheaper to just use GSuite than to use this?
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.)
This is a Premium Edition, the Free Edition is what is included with GSuite:
https://support.google.com/cloudidentity/answer/7319251
https://support.google.com/cloudidentity/answer/7319251
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.
I'm talking about SAML setup for GSuite.
https://aws.amazon.com/blogs/security/how-to-set-up-federate...
https://aws.amazon.com/blogs/security/how-to-set-up-federate...
Anyone compared this to Azure AD?
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.
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.
Thanks. This differentiation seems to be purely based on the pricing -- the feature set is perfectly usable for a SaaS offering.
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.
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.
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.
https://support.google.com/cloudidentity/answer/7319251
https://support.google.com/cloudidentity/answer/7319251
>Google for Work
The current name for this product is G Suite.
The current name for this product is G Suite.
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.
This price point doesn't make sense outside of the niche SaaS offerings that can charge in the thousands per month.
Cognito doesn't address the same use case.
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.
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.
The equivalent AWS product is AWS SSO [0] which requires a Directory Service instance (circa $100/mo)
[0]https://aws.amazon.com/single-sign-on/
[0]https://aws.amazon.com/single-sign-on/
> 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.
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.
[deleted]
[deleted]
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.
Given the recently revealed consequences of people using a major third party (Facebook) for user authentication is this really going in the right direction?
This is about managing the identities and permissions of employees, not end-users.
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?)
Yes, they are disjoint, and no, you don't need two browsers, Gmail can handle two different accounts in the same browser simultaneously nowadays.
[deleted]
Is this a re-brand of Google's Beyond Corp?
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.
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.
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.
It also might be a product, Google's Identity Aware Proxy (IAP). https://cloud.google.com/iap/
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.
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.
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).
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.
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.
It is becoming more and more difficult to trust companies that have their fingers in too many pies.
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!
Edit: Spelling
Edit: Spelling
Yeah, I asked Eric Sachs (who runs the identity efforts at Google) and others a few times over the years. They always directed me to Okta, Ping, etc.
Eric Sachs no longer runs identity at Google. You have your explanation why right here.
Hah, interesting. His old site is still up https://sites.google.com/site/ericsachs2/ but at least his LinkedIn page is up to date. Thanks!
They acquired Bitium. An identity as a service is in the works. Since the Oktas and Onelogins have virtual LDAPs I’m sure that will be coming as well.
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.
[0] https://cloudplatform.googleblog.com/2018/03/introducing-new...
[1] https://cloudplatform.googleblog.com/2018/03/expanding-our-G...
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...
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.
Don't get me started on radius...
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...
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.
Is this actually a competitor to AD?
Is this actually a competitor to AD?
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:
https://github.com/apereo/cas
https://www.univention.com/products/ucs/
https://www.shibboleth.net/
https://wso2.com/
One of my planned side projects is to test each of these.
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://github.com/apereo/cas
https://www.univention.com/products/ucs/
https://www.shibboleth.net/
https://wso2.com/
One of my planned side projects is to test each of these.
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.
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.
Gitlab already has several plugins for auth, for example you can use OmniAuth to have users login with an external identity provider: https://docs.gitlab.com/ee/integration/omniauth.html
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.
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.
Ah - cool. That makes sense!
Page is broken on iPhone SE. Overflow hidden larger than viewport.
Unfortunately, poor mobile usability on their dev sites is very common for Google, which is something I could never understand
Unfortunately, poor mobile usability on their dev sites is very common for Google, which is something I could never understand
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 :(
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 :(
[deleted]
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.