I am getting confused on these 3 terms. What I know OCI is infrastructure provided by Oracle, IAM is user and IDCS is Identity cloud service. But I dont understand differences and terms.
Is IAM user and normal user are same?
is OCI and IDCS are same?
What exactly IDCS is?
Let me try to answer your questions:
IAM or Identity Access Management is a tool designed to control who access to your cloud services. IAM user is an user who access to a service in your Cloud. What do you mean by normal user I cannot know.
OCI or Oracle Cloud Infrastructure, is a deep and broad platform of cloud services that enable you to build and run a wide range of applications in a scalable, secure, highly available, fault-tolerant and high-performance environment.
Oracle Identity Cloud Service (IDCS) is an Identity-as-a-Service (IDaaS) solution available in Oracle Cloud. It is designed to extend enterprise controls by automating PaaS and SaaS account provisioning and deprovisioning, simplifying the user experience for accessing cloud applications by providing seamless integration with enterprise identity stores and authentication services, and facilitating compliance activities by clearly reporting on cloud application usage.
Although it look like IDCS and IAM might look the same, they are designed to different purposes. IDCS is focused on SaaS or PaaS services by integrating itself with identity stores as Active Directory or LDAP inside organizations. IAM is designed to control Cloud resources providing access to each component, like a block storage or a computer instance.
Hope it clarifies a bit.
Regards
First of all
OCI refer to Oracle Cloud infrastructure and it's cloud computing solutions same as MS azure or amazon AWS, but offered by Oracle and it's providing various services such as servers, storage, network, applications and services through a global network of Oracle Corporation managed by different data center around the world.
IAM refer to Identity and Access Management this is services allow you to control who can access to cloud resource and even control what type of access they have, and to which specific resource, there is different Components of IAM such as resource, user, group and more you can check Oracle documentation that provide also examples here
IDCS refer to Oracle Identity Cloud Service and it's consider as Identity-as-a-Service (IDaaS) solution, Oracle Identity Cloud Service provides identity management, single-sign-on (SSO) and identity governance for applications on-premise, in the cloud and mobile applications , Any user can access the application at any time, anywhere on a device in a secure manner. Oracle IDCS integrates directly with existing directories and identity management system, making it easier for users to access applications. Providing a platform that is robust and secure, allows users to access, develop and deploy their applications.
Check the documentation here
The benefits of implementing Oracle Identity Cloud Service are; Improved Business Responsiveness, Enhanced User Productivity and Experience, Hybrid Multi-Channel Access and finally Simplified IT and Reduced Cost.
In addition to the answers above, IDCS can play role of IDP for federated login to Oracle Cloud Infrastructure console.
Related
Can somehow explain me the difference in these products?
As far as I understand IBM ACE (AppConnect) gives you more or iPaas capabalities. It is allows you to make an API.
But from what I understand now is that API Connect is required for the actual API management. Proxy/policies etc.
Does anyone know you these products are licensed? Do you have to API connect for your APIs to be managed, governed etc?
This is not an exhaustive answer, but hopefully it'll point you in the right direction...
App Connect is for building integrations (flows) with various data sources. Could be databases, cloud services like GSuite or Salesforce, or even HTTP endpoints. Those flows could be triggered by events in one of those systems or by an API. You can also do things like turn a database schema into an API. You get the idea.
API Connect is for API governance, security, and socialization. In more concrete terms, it gives you tools for things like: adding authentication and/or authorization to all APIs, bundling APIs together, enforcing rate limits or quotas, providing a portal for sharing/selling your APIs with others, and so on.
You can create APIs using App Connect and stop there--it's usable/invokable without API Connect in the picture. API Connect provides enforcement policies to give you more flexibility in how you call that API and/or give others the ability to invoke the API. The two products complement each other, but an API management product would be required in order to manage and govern the APIs created by App Connect.
In terms of licensing, there are multiple available options. You can purchase the products as standalone software packages that you install and maintain yourself (see IBM Cloud Pak for Integration) or you can leverage the IBM-managed versions that IBM provides via IBM Cloud.
More information is available:
https://www.ibm.com/cloud/api-connect
https://www.ibm.com/cloud/app-connect
https://www.ibm.com/cloud/cloud-pak-for-integration
I administrate users in Cloud Identity Free Edition now.
They can't use Google Drive, Colaboratory, Spread Sheet, and so on after they started being controlled in Cloud Identity.
What should I do to allow them to use those services again with controlling them?
Should I switch Free Edition to Premium Edition or GSuite?
Correction to my answer earlier to this topic.
Google Drive is actually present in Cloud Identity Free and Premium Edition.
It is just limited to 15GB per User. Just have a look at the Cloud Identity Core Services
You have to activate it in the Admin Console (https://admin.google.com), and after that it is available for all users in the domain, Organizational Unit or group, that you have chosen to activate it for.
If you need additional configuration options to control the access to drive and the sharing possibilities in your domain, you should however switch to a G Suite Licence
I am currently working heavily in Azure. I am actually quite fond of ARM (Azure Resource Manager) right now and would love to keep using it. Right now in the old portal, We have a lot of resources tied up as Cloud Services. Now, I know cloud services are available in the new portal, but it seems that Microsoft is moving away from the classic cloud service model. Can someone explain if this is true? If so, what will the new model look like? I already use resources groups to manage Websites (WebApps), so I assume this is where the azure future lies. Will we see the "deprecation" of cloud services on down the line?
I am trying to understand if I need to begin re-structuring my Azure Infrastructure.
Any insight, explanation, or documentation is greatly appreciated.
So there are two things here - Cloud Services and managemenet of Cloud Services.
When you manage Cloud Services in current portal the underlying mechanism used is Azure Service Management (ASM) where as it is Azure Resource Manager (ARM) in the preview portal. To me, ARM is the new way of managing your Cloud resources in Azure (including Cloud Services).
I don't work for Microsoft so I would not know if Cloud Services themselves will be deprecated down the road or not but one thing I think will happen is that ASM will be deprecated in favor of ARM. At some point of time, the only option you will be left with managing your cloud resources will be through Azure Resource Manager. One example that makes me believe this thing is the presence of Classic resource providers (e.g. Classic Storage Resource Provider which enables you to manage storage accounts created in current portal via ASM in the preview portal which works exclusively on ARM).
Personally I can't see a place for cloud services in the new ARM world of Azure. I have always found them a convoluted concept that simply added complexity to a deployment.
In the ARM view of deployments servers are collected together in a VNet, and each server is attached to a Nic which in turn can be connected to the internet. A security group then takes care of ingress / egress rules.
This is a much cleaner deployment method, as it puts connectivity configuration at the server layer instead of mapping them all through a higher layer of abstraction.
I don't see the place of cloud services in ARM, however after a quick search it seems that there is a plan to implement it
Still no direction from the Azure Advisers group other than officially they will not drop support for Cloud Services. I think they are nearing giving us some kind of direction but I can't say anymore than that.
I asked a question about the future of Cloud Services on the recent Azure Compute AMA.
You can read the answers directly on Reddit for all details, below are a few interesting quotes (emphasis mine).
On ARM Integration for Cloud Services:
We are looking at ways to make the transition to ARM easier for Cloud Service customers- one of those options includes CS integration in ARM. This investigation is in the very early stages though, so if you are looking for a solution soon, check out VMSS/ACS/SF/Web Apps (meagan-msft)
And:
I think it's safe to say that if we make any significant investment in CS in the near future, it would be ARM integration, and as Meagan suggests, that's still in planning. Beyond that, there are no major feature improvements on the horizon. We believe the platform is pretty mature at this point. (seanmichaelmckenna)
So it doesn't look like any major innovations will hit Cloud Services soon, however:
Cloud Services are not going anywhere. In fact, many Microsoft services run on Cloud Services, so we heavily rely on them as well. They are fully supported, so feel free to continue to use them.
(meagan-msft)
For those who want to switch to a different Compute service, these recommendations were made:
However, if you would like to check out other services that are integrated with ARM today, we recommend checking out the following:
Web Apps for customers who want a fully managed platform and are building traditional web applications
Service Fabric for customers who want an opinionated application platform and managed infrastructure, but still need some control over the IAAS layer
VM Scale Sets for customers who need IaaS-level control with easy scaling, autoscale and load balancer integration
Azure Container service was also listed as a potential alternative.
Some things to consider (my understanding):
Service Fabric currently (2017) requires at least 5 VM instances, except for dev/test purposes. So probably only an option for larger services
VM Scale Sets is an IaaS offering, i.e. you have to manage OS updates etc. yourself. However, support for automatic OS updates is being worked on.
I'm currently developing a WP7 app, and I'd like it to talk with my SQL Azure database. I know there are currently two ways of doing it:
Talk to a WCF Service hosted on my web server.
Use oData to communicate with my database.
I don't know what's the pros and cons between the both of them, but I know that using the first method involves two remote calls: one: to the web server, and two: from the web server to SQL Azure. Would using oData allow me to directly communicate with my SQL Azure database? Does SQL Azure provide a REST interface for my WP7 client to work with?
If you use the WCF service approach and host the service on our web server (i.e. not in an Azure Web Role) then yes there will be two higher latency hops across the network. However the WCF service does have the benefit of allowing you to provide your own security approach for your mobile clients. I suspect that this app will be used by more than just a couple of people? If you take the approach of talking directly to the SQL Azure oData endpoint then you will really struggle with Authetnication and Authorization. It's not really designed for supporting your scenario.
The other thing to note with the SQL Azure oData endpoint is that it never left SQL Azure Labs; i.e. it was never actually shipped as part of the product and the Labs implementation is end of lifed and grandfathered to existing users only.
I know that doesn't really answer your question; the short answer is that there is no RESTful endpoint that you can access to talk directly to SQL Azure. The long answer is that even when there was one you probably didn't want to use it.
Without knowing more about your app it's a little hard to give guidance as to exactly what you should be doing. If you can provide a bit more detail I can provide some advice as to which Azure data storage technology would be best suited.
I am trying to understand exactly an AppFabric in Windows Azure, What is the difference with Worker Role and Web Role and How to create a project of AppFaric in Visual Studio 2010, i mean which kind of project ?
Thx.
Adding a bit to vtortola's answer:
There are three core areas of the Windows Azure platform:
Windows Azure (which provides virtual machines and massively-scalable storage through Blobs, Tables, and Queues
SQL Azure (which is a large subset of SQL Server), offering a full relational database up to 50GB
Windows Azure AppFabric (a set of services that you can opt into, currently comprising access control, connectivity, and caching)
When you construct your Windows Azure application, you can really pick and choose what pieces of the platform you're interested in. For instance, Windows Azure provides Web and Worker roles (both essentially identical virtual machines running Windows Server 2008 or R2, but Web roles have IIS enabled). If you need a relational database, you can very easily set up a database. And, then there's AppFabric:
If you need to connect to a set of web services on premises, for instance, you can use the AppFabric Service Bus (a secure way to connect without having to open up a firewall)
If you need to actually connect to an entire computer on-premise, use Azure Connect (a software VPN).
If you want to cache data (such as asp.net session state) between instances of your virtual machines, enable and use the AppFabric Cache (currently a Community Technology Preview, so no pricing yet).
If you need to add access control to your application, use AppFabric's Access Control Service, which essentially lets you outsource your identity management.
There are quite detailed examples in the Platform Training Kit that vtortola referenced. Additionally, there's a complete Identity Management training kit.
Azure AppFabric is a suite of middleware services and technologies to help you develop and manage services/applications that use Windows Azure. Middleware is typically defined as software that helps connect other pieces of software, and this definition is pretty accurate for the services appFabric provides.
You don't create an App Fabric per say. AppFabric services are used by your other applications as needed, so setup is typically configuring certain items in the Azure Portal, then implementing libraries of config entires in your web/worker roles that leverage the resources.
Essentially AppFabric provides certain resources that you need when composing complex applications as services, vs. you having to implement and maintain these resources yourself.
The basic offerings are:
Service Bus: A message relay that can be consumed by other .NET technologies (and others). SB helps you connect different cloud services as well as "hybrid" services. The hybrid is a big deal, as SB helps you easily connect on-premise web services with services you run in the cloud, w/o having to mess around with VPN, protocols, server setups, certificates, etc etc.
Access Control: An authentication and authorization service, helping you manage user-level access without having to extend/implement Active Directory, LDAP, and custom user authentication modules throughout Azure.
Caching: an in-memory distributed caching layer for your applications. This is typical to memcached or the Windows Server version of AppFabric
Integration: a PaaS service of EDI/transport technology like BizTalk server
Composite App: allows the composition of complex applications using a compistion language versus just putting a bunch of code together. You basically define your application using a designer like you would a EF.Net data model or a Windows Workflow
So basically AppFabric provides you with a lot of services that you likely need, but the typical cloud developer may not want to "mess with" at least at first. This way you have these great building blocks to help you focus on your core logic/needs during development cycles while not limiting what your application can ultimately do. This "focus" is one of the core benefits to cloud computing, especially Platform as a Service, and is one area where Azure really shines compared to other offerings.
Some of these technologies are still in beta. The AppFabric site makes this very clear, but its important to be aware of.
Great place to start is the Azure AppFabric site itself, which breaks a lot of this down, gives you great examples of how to use, and some sample code for you to get your feet wet.
http://www.microsoft.com/windowsazure/AppFabric/Overview/default.aspx#top
Basically:
WebRole : similar to a web
application.
WorkerRole: similar to a Windows
service.
AppFabric: Group of services that
allow you interconnect applications inside and outside Azure.
Download and read/do the Azure training kit, it will solve those questions and tell you how to create that project in Visual Studio step-by-step.