I am planning to use Auth0 service for Chinese users. I noticed that there are no servers that are hosted in China, and because of that my main concern is the firewall that China has. Weather my azure hosting web application will be able to access Auth0 in Australia.
https://auth0.com/docs/api/authentication?http#code-samples
I have a server that is in China and was able to call Auth0 api, but I am not sure how reliable that is. As the authentication and authorisation is so critical that the system I am building will stop working once the app can't access the service. Has anyone done the same integration especially for China and can share their experience?
The great firewall of China has blocked many CDN providers such as AWS CloudFront/S3, Google PageSpeed, Cloudflare, etc, causing an outage for some users in the China region. Auth0 uses AWS servers so China may restrict access. It is previously been reported that cdn.auth0.com fails to load in China.
If you use the Lock library as the login widget from Auth0 CDN, there are workarounds for this.
Lock library references two files:
Client configuration files (JS files that have information about connections enabled for the application, application metadata, etc)
Language files (For Lock Internationalisation)
You would need to change the location where Lock fetches these files using the clientBaseUrl and languageBaseUrl options. Note that any change made to an application configuration means updating the mirror file in your server too.
Related
If you were to build an enterprise SaaS app today, what would be the preferred protocol/endpoint to obtain the list of users, emails and groups from an Azure AD deployment?
Historically this was done via LDAP connection to an Active Directory Domain Controller, and I see that Azure offers an LDAPS service (Azure AD DS).
ADFS, which is quite widespread, is just a SAML-compatible IdP, but it doesn't seem to provide an API for listing the directory of users.
The Microsoft Graph API seems to be able to provide at least some of this information, but it seems to be fairly new and very widespread. There's also something called SCIM that appears to have broader support, but it doesn't seem to be super popular on enterprise cloud apps either.
My research has shown that the apparent right answer for this problem is to implement SCIM 2.0 APIs on the product.
The main annoyance of the approach is that SCIM 2.0 is a protocol that is triggered by the directory provider (i.e. a SaaS app will receive an API call from Azure AD when a user needs to be created or updated, instead of the SaaS app contacting a directory endpoint to fetch the information when it is needed).
This creates a few annoyances such as potential race conditions when updating user information in the middle of application processes, or the fact that updates to the directory can't be triggered at convenient times (such as nightly, for example). Debugging/testing is also more problematic.
In web system, when some URL is protected, user is redirected to dedicated auth-page, and after login is (in convenient case) redirected back.
I understand that with mail.google.com and accounts.google.com the reason is huge google infrastructure, and may be different developer groups responsible for accounts and mail. And if I want to make user authenticate using Google, I become a part of it.
But in a average web app I can just do like hasAuth() ? renderProtected() : renderLoginDialog() without any redirects.
Tutorial for react router is showing example with redirects, and materials for server-side frameworks is about to do the same.
Is there any practical benefits (like security) of redirect based solution, or it's just following the trend from the giants?
This is a common implementation of Single sign-on - SSO. You basically sign in once in a dedicated server, and then you can access multiple applications which are not related without signing in again. For example, after sighing in to your google account you can access all google applications (gmail, drive, calendar ...)
We are developing asp.net core applications that will require sending emails with gmail among other providers (client accounts). This applications will not be hosted by us but by many of our clients.
The application may be hosted on their domain or no domain at all (IP address only).
I am struggling with which authorization process I should use since I can not use the Javascript client or any redirect URI method due to unknown origin/domain. I also can not use localhost origin since there is no way for me to start a local http server from a browser. Programmatic extraction is deprecated. The only thing I am left with is manual copy/paste but apart from it being very user unfriendly Google documentation states that that might be deprecated in the future as well.
Am I missing something?
Please point me in the right direction as to how I should proceed.
We currently have Azure Active Directory with several thousand users in Active Directory. What does IdentityServer4 provide that I cannot get with connecting my .NET and/or Java apps to AAD alone? Can AAD provide me with an auth token that can be used to access the front-end app as well as the back-end API?
The key benefit is control (you can model your clients and resources and taylor your UX as you see fit) and the ability to use it as a federation gateway. E.g. if you need to support multiple customers many of which may want integration to their own IDP.
I have a web based application which is used to find information about various assets in a facility. This provides only search capability, no CRUD operations allowed from the application (except for READ). This web application is always kept open in a touchscreen device (ie workstation) and this could be used by any of the facility staff. The user does not want to initiate login and logout for each of the search operation.
We are planning on deploying the web application onto the cloud. Although it is not a need to authenticate the user who is accessing the web-application, it is still a need to ensure that information about assets in the facility are not accessible by others. How do I build this authentication layer? The various options I can think of are:
1. Include userid/password in the URL as parameters. I could create a userid/password for each of the facility. Simple, but userid/password area always visible.
2. Certificate based approach. Certificates are created for each of these workstations and deployed on those workstations. Quite secure, but has the challenge of managing the certs life-cycle. As well challenge of configuring the web-servers with certs from different facilities???
Any suggestions?
Thanks,
Prasanna
A simple, but not secure thing. Do an IP check and if the IP is from your facility then grant access.
The second, but secure method is to do a verification at the start of the application with just a password and store a session , so that you will know that people from your facility are accessing the site..