The Google Identity Platform documentation only mentions MFA via SMS. Are procedures like TOTP really not supported? Is that planned for the near future?
For a sophisticated corporate application, it seems necessary to me, both for security reasons and for the cost of SMS.
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
My enterprise application is developed in .net framework 4.5 and is using windows authentication. In which case, as we all understand, it is the underlying AD(active directory) that authenticates the user.
I have to replace windows authentication with token based authentication, keeping the .net framework 4.6 and AD(active directory). I guess oAuth is a possible solution, could you please share some thoughts on other possible solutions and as how could I get started.
HISTORY
It was common some years ago for apps to be developed for a corporate intranet, in which case Windows Authentication was a good solution. When token based authentication came along the benefits typically were:
Extend reach so that apps could be used over the internet
Support cross domain scenarios, eg APIs in a different domain
Support multiple authentication methods / policies depending on user location and device type
Write less security code and make new security features available to multiple apps
IMPLEMENTATION
An OAuth migration is a major architectural change and needs to be managed in terms of costs and benefits, though once done your apps will be quite cutting edge. Here is how Windows Authentication typically works in an OAuth 2.0 / Open Id Connect world, which requires a more complex setup:
Your UI redirects to a Cloud Authorization Server (AS), such as Azure Access Control
The AS redirects to an identity provider - such as an on premise version of ADFS (Active Directory Federation Services) - that is configured to use Windows authentication
When in the corporate intranet the user is automatically signed in and ADFS posts tokens to the AS
The AS posts different tokens to your UI
Your UI calls the API with the AS token and the API validates it
GETTING STARTED
If you decide that the effort is worthwhile then there are 2 parts to the job. Note that your application code will only ever interact with the AS and doesn't need to know or care about the authentication method:
Infrastructure migration
Updating the code in your UIs and APIs
If it helps, my blog and code samples are designed to help people deal with some of the challenges of OAuth tech. Maybe have a look at my first tutorial to get set up.
I have implemented an application which accesses calendars in an Office 356 E3 tenant. I've used the client_credentials flow and obtained Admin Consent. So far everything seems to work as expected.
Now I have a customer how wants to use my application with an Exchange 2016 on-premise setup. Is there a way to use the same application in this setup as well? Or do I have to implement a new application using EWS?
The graph API is not available on on-prem Exchange, so yes, you have to replace the graph API code with EWS code.
Depending on your use case, it is probably possible to abstract it such that your application can use either one or the other.
We had a similar issue.
You can change from Office365 Api to the MsGraph Api which supports many of the same features as the Office365 Api does. Your on premise customer needs to put his Exchange servers into hybrit mode for this. MS explained the necessary steps here.
The only problem we had is that you cant subscribe onto on premise calendars.
Here is the MsGraph Api doc
https://learn.microsoft.com/en-us/graph/api/overview?view=graph-rest-1.0
You can also consider switching from Office365 to MsGraph entirely as this should also work for you Office365 customers. As I understand it MS is gonna expand the MsGraph Api in the future giving us a single point of contact for interaction with the Office suite and authentication.
#Marc LaFleur pls correct me if I'm wrong on this
what is the purpose of enabling API in the Google developer console? Is it just for monitoring / fees / etc? If an app is using OAuth 2.0, you can tell from the token the identity of the app so you can just monitor that way. What is the purpose of this additional step?
Thank you for your help.
As you've already mentioned, it is for monitoring traffic, enforcing quota, and handling billing. An application does not necessarily have to use an OAuth 2.0 token to access Google APIs though. There are cases where when accessing APIs that do not require user data, API keys can be used instead. It also would not make sense to simply have all APIs enabled, as it is more reasonable to only activate the ones you need.
I have read about new Google Apps Marketplace and have seen the overview video here.
I'm worried about migration from OAuth1 to OAuth2 and having impact to some developed applications with APIs in my domaine
in the video exactely in 24', comparaison of what libraries/APIs are used in the OAuth1 vs OAuth2, and in 27' talking about turning off the OAuth1.
these Libraries/API will be deprecated ?
Any idea about turning off the OAuth1 and when ?
You need not worry about the impact of OAuth1 to OAuth2. This transition can be completed in a max of 15 days if you have done many integrations with Google. If you are worried just about the SSO with OAuth2 this can be completed in a day as Google has already provided proper documentation regarding the work flow.
Google has even provided migration APIs to upgrade your customers domains from v1 to v2 of Google Apps Marketplace(GAM). If you have a huge user base to be migrated then you need to plan accordingly such that migrated and non-migrated users would be able to use your app for some days till the migration is completed successfully.
Google will announce if it intends to discontinue or make backwards incompatible changes to this API or Service. Google will use commercially reasonable efforts to continue to operate those Google Documents List API versions and features identified at http://developers.google.com/google-apps/documents-list/documents-list-api-list without these changes until April 20, 2015, unless (as Google determines in its reasonable good faith judgment):
So on a safe side it is better to migrate all of your APIs to the latest libraries to avoid any failures at a later point of time. Anyway the older versions are not supported for any issue fixes/ support from Google side. So it is always better to migrate your APIs
Older version of GAM(v1) will also be deprecated at some time but Google hasn't provided any timeline for this. Probably it may take a year(not sure)
Google strongly encourages you to migrate your marketplace application to OAuth2 as soon as possible. Google has already announced deprecation of OAuth1. All top apps on marketplace have migrated their customers to OAuth2 with no issues. We plan to stop allowing installs of OAuth1 applications in near future from the marketplace (specific timelines to be communicated separately).