#CloudIdentity

[anusha-g]

What is the difference between Azure AD and Active Directory?

Azure Active Directory (Azure AD) and Active Directory (AD) are related but serve different purposes. Here are the key differences between the two:

Location and Deployment:Active Directory (AD): It is an on-premises directory service provided by Microsoft. AD is used to manage and authenticate users, devices, and resources within a Windows-based network.Azure Active Directory (Azure AD): It is a cloud-based identity and access management service provided by Microsoft as part of the Azure cloud platform. Azure AD extends identity services to the cloud and supports identity management for applications and services.

Scope of Management:Active Directory (AD): Primarily focuses on managing resources within an organization's local network, including user accounts, computers, groups, and domain services.Azure Active Directory (Azure AD): Designed for managing identities and access for cloud-based applications, as well as providing identity services for users accessing resources outside the traditional corporate network.

Authentication and Authorization:Active Directory (AD): Provides authentication and authorization services within the on-premises network, allowing users to log in and access resources.Azure Active Directory (Azure AD): Offers cloud-based authentication and authorization services, allowing users to access various Microsoft and third-party cloud services, applications, and resources.

Integration with Cloud Services:Active Directory (AD): Generally not designed for direct integration with cloud services. It is primarily used for on-premises environments.Azure Active Directory (Azure AD): Specifically designed for cloud integration and works seamlessly with various cloud-based applications, including Microsoft 365, Azure services, and third-party applications that support Azure AD authentication.

Use Cases:Active Directory (AD): Commonly used in traditional on-premises environments to manage user identities and resource access.Azure Active Directory (Azure AD): Suited for cloud-based and hybrid environments, providing identity and access management for cloud services, SaaS applications, and mobile scenarios.

[awsexchage]

G SuiteとCloud Identity https://ift.tt/2TclLyf

雑記。 G Suite初心者、すごく混乱したのでメモ。

Cloud Identityのユーザー追加を試してみようと思った。 が、これってG Suiteのユーザー追加なのか？と悩みだす。 Cloud Identity Freeのユーザー追加は無料だけど、G Suiteだとお金がかかってしまう。。。

ドキュメントみてみたけど、ほぼ同じ。

G Suiteでのユーザー追加：　https://support.google.com/a/answer/33310

Cloud Identityでのユーザー追加：　https://support.google.com/cloudidentity/answer/33310

まぁ、￥６８０、最悪１食我慢すれば取り返せるだろうと、エイヤ！とユーザー追加。

めでたく、Cloud Identityのユーザーとして追加された模様。 メールなどの機能が限定されたユーザーが出来上がる。

Cloud IdentityのユーザーのGoogleアプリパネル

G SuiteユーザーのGoogleアプリパネル

のちのち、色々調べると、Cloud Identityユーザー追加時にG Suiteユーザーに自動的にライセンス付与するようにしておくと、Cloud Identityユーザー追加＝G Suiteユーザー追加になる模様。 デフォルトOFFっぽいですが、Cloud Identityユーザー追加時には確認しておいた方がよさそう。

元記事はこちら

「G SuiteとCloud Identity」

February 25, 2020 at 12:00PM

[building4-blog]

Notes on the Cloud Identity Summit - Guest Post from Zane Rockenbaugh

A couple week ago, we held out second Cloud Summit, the Cloud Identity Summit. It was a fun afternoon talking with several, local identity experts and users. One of the attendees, Zane Rockenbaugh of Liquid Labs was kind enough to share his write-up of the event, below:

What is identity?

Identity consists of set of identifiers, authorization credentials, and a small set of extensible attributes and endorsements.

What isn't identity?

More expansive definitions for identity certainly can make sense, but for purpose of creating a real world, technical system, it is necessary to separate "identity" from "data" in general. E.g., from the standpoint of "you are what you do", your shopping history is part of or your larger identity, but for the purpose of this statement, that kind of information would be considered out of scope.

What is cloud identity?

Classic cloud identity is conceived as a portable, comprehensive, and extensible identity. Control and management of identity would be focused on the identified entity itself, and while not entirely centralized, use and flow of identity would be more transparent.

What are the benefits?

By locating primary control of identity with the entity itself, it necessarily follows that “utility friction” would be lessened and that total utility would be increased [if people control their own identity, it's probably easier for them to use it -Cote]. With the necessary technical, legal, and social framework we would expect to see privacy rights strengthened and while the exchange and value of information would simultaneously increase.

What could this look like?

The most likely form would be:

An open, easily consumed container format, likely some XML variant.

A small set of core attributes “that (most) everyone can agree on”. Core identifiers, such as “user name” and email may be reasonably defined by existing specification or fiat. Personal information (name, address, etc.) is tougher, but also not critical to the basic operation.

Extensible modules. Some identity information may be understood by some consumers and not others. These boundaries would need to be made clear.

Clear access rules that are based on who is asking for what and under what context. E.g., a cellphone carrier can get my credit card for billing, but not for basic support.

For the classic conception to be made real, the identity itself has to be housed at a third party identity provider who services the individual whose identity is being stored. Any other arrangement would effectively fragment the identity.

What are the key obstacles?

The preponderance of existing business models view “identity” and related data as a proprietary asset of the company. A lot of the value of Google and Amazon is in what they know about the customer.

One can imagine a stable and economically rational world in which Google (etc.) is properly incentivized to recognize a “cloud identity” rather than forcing the user to create a proprietary identity wholly owned by Google, but getting from current reality to that reality would be very difficult.

One of the difficulties in bridging the chasm is the value proposition for a company offering a cloud identity service. Such a business would, by definition, not own the data it manages on behalf of the customers, so how it would be financed is unclear. If such a business existed and had critical mass, it could be viable, but again, how does one get from here to there?

There are also a host of regulatory concerns which would make participation by certain domains (namely healthcare and banking) difficult and potentially—at least without major changes to the regulations—impossible.

What could be done today?

Rather than focus on a theoretical “cloud identity”, it makes more sense to focus on the benefits such a system could provide and ask, “Is there a way to provide that specific benefit now?”

Cloud services pose a problem for organizations that need to control access to information, manage brand, and manage authority. “Hoot Suite” is a tool that provides for corporate (in the older, broad sense) management of individual Twitter accounts. The same concept could be expanded to many cloud services to provide a point of necessary control in service access and usage. In the ideal case, there would be one service that would provide single point control and provisioning for all the underlying cloud services which would appear as modules within the identity management service.

Many cloud services offer business accounts which allow the business to create an virtual instance of the service with additional controls for the business. Google is an example. This approach solves some of the problems mentioned above, but doesn't do anything to centralize identity management. From the standpoint of evolving a cloud identity, service providers would be best served by designing robust APIs with the appropriate concerns in mind.