I am currently learning SCIM and one thing that I have come across is the SCIM endpoints need to be on the public DNS so IdPs can call out to them. I have used ngrok to expose my localhost over the internet for testing purposes but I was curious if there is any way I can accomplish this by not exposing my SCIM endpoints on the public DNS. I believe with Azure AD this is possible via the Azure AD Provisioning agent but I was wondering if there was an alternative like the Azure Provisioning agent or anything else for other IdPs such as Okta or PingOne.
Thank you
The SCIM protocol, at RFC-7644, doesn't specify anything about the implementation details of a provisioning agent. The protocol dictates the language that both the IdP and the target domain app will have to share. It doesn't even dictate the authentication layer.
But your point is valid: what if your SCIM REST API has to be network-gated?
A provisioning agent is purely an implementation-specific component that different identity providers opt to provide their admins as a means to allow SCIM provisioning in network-gated environments (e.g., the Azure AD Provisioning Agent and the Okta Provisioning Agent). If your SCIM REST API is gated behind network constraints that disallow the IdP's direct network access, you'll need an agent, but it's important to stress that the agent itself is not part of the SCIM protocol.
In other words, a provisioning agent is a courtesy given to you by your identity provider and not the SCIM 2.0 protocol.
Whether you seek to set up your development or production environment, how your IdP interacts with that environment's SCIM REST API is a decision to be made - agent or no agent. As for your local development environment, it's entirely up to you to decide whether you keep using a reverse tunnel like ngrok or decide to install your IdP's agent on your development stations.
A side-note on event-driven architecture:
I recently wrote a blog post on SCIM 2.0 provisioning on a high level. The idea is simple: instead of "scraping" the state of the identity provider's user pool, you're switching to an event-driven mindset, wherein the IdP informs your SCIM tenant (i.e., your SCIM REST API) of movements in your user pool. Switching to working with an agent kind of augments the idea behind that event-based architecture of SCIM 2.0, but it does work around the network constraint that a lot of organizations have.
Related
I have two webapi projects which will be deployed as two different websites on the same server - server/site1 and server/site2. They both use token authentication. Can I have a third webapi project with just the token endpoint that is deployed at server/tokensite so that the token retrieved from here can be used for authentication on site1 and site2?
Your Problem
I have two webapi projects which will be deployed as two different websites on the same server - server/site1 and server/site2. They both use token authentication. Can I have a third webapi project with just the token endpoint that is deployed at server/tokensite
I would prefer to deploy on same server, but using sub domains:
site1.example.com
site2.example.com
auth.example.com
This gives you the flexibility to move things around servers more easily.
so that the token retrieved from here can be used for authentication on site1 and site2?
Yes you can, but as I already mention I wouldn't do it in the same domain.
So it seems that what you are trying to implement is Single Sign On(SSO)
Single sign-on (SSO) is a property of access control of multiple related, yet independent, software systems.
Conversely, single sign-off is the property whereby a single action of signing out terminates access to multiple software systems.
Other shared authentication schemes such as OpenID, and OpenID Connect offer other services that may require users to make choices during a sign-on to a resource, but can be configured for single sign-on if those other services (such as user consent) are disabled.
So to achieve SSO you can use OpenID Connect:
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
OpenID Connect performs many of the same tasks as OpenID 2.0, but does so in a way that is API-friendly, and usable by native and mobile applications. OpenID Connect defines optional mechanisms for robust signing and encryption. Whereas integration of OAuth 1.0a and OpenID 2.0 required an extension, in OpenID Connect, OAuth 2.0 capabilities are integrated with the protocol itself.
Possible solution
I don't advise you to implement your own solutions, instead delegate it to an Authentication provider, or use an Open Source package to implement it.
It seems you are using DOTNET, thus I would recommend you to read this quick start on their docs, that guides you through of setting up SSO in a new project with some official libraries.
In this quickstart, you'll learn how to implement sign-in with Microsoft using an ASP.NET MVC solution with a traditional web browser-based application using OpenID Connect. You'll learn how to enable sign-ins from work and school accounts in your ASP.NET application.
Alternatively you can use SSO from Azure Active Directory.
Single sign-on (SSO) adds security and convenience when users sign-on to applications in Azure Active Directory (Azure AD). This article describes the single sign-on methods, and helps you choose the most appropriate SSO method when configuring your applications.
For anyone reading this, but using other language, see some examples of SSO packages for:
PHP.
Python.
NodeJS.
Going the Extra Mile
Once you are deploying your own solution I would recommend you to invest heavily in securing it. For an API serving a web app you can employ several layers of defense, starting with reCaptcha V3, followed by Web Application Firewall(WAF) and finally if you can afford it a User Behavior Analytics(UBA) solution. If you want to learn and understand why is important to secure properly an API, you may want to read this series of articles, that will teach you how API Keys, User Access Tokens, HMAC and TLS Pinning can be used to protect the API and how they can be bypassed. While the series of articles are in the context of a mobile api, lot of it is still valid for a web api.
Google reCAPTCHA V3:
reCAPTCHA is a free service that protects your website from spam and abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive challenges to keep automated software from engaging in abusive activities on your site. It does this while letting your valid users pass through with ease.
...helps you detect abusive traffic on your website without any user friction. It returns a score based on the interactions with your website and provides you more flexibility to take appropriate actions.
WAF - Web Application Firewall:
A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to and from a web application. A WAF is differentiated from a regular firewall in that a WAF is able to filter the content of specific web applications while regular firewalls serve as a safety gate between servers. By inspecting HTTP traffic, it can prevent attacks stemming from web application security flaws, such as SQL injection, cross-site scripting (XSS), file inclusion, and security misconfigurations.
UBA - User Behavior Analytics:
User behavior analytics (UBA) as defined by Gartner is a cybersecurity process about detection of insider threats, targeted attacks, and financial fraud. UBA solutions look at patterns of human behavior, and then apply algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats. Instead of tracking devices or security events, UBA tracks a system's users. Big data platforms like Apache Hadoop are increasing UBA functionality by allowing them to analyze petabytes worth of data to detect insider threats and advanced persistent threats.
So I want to have single sign in, in all the products using a auth server but that's not only for employees, keycloak should be used to that like auth0?
There are also some advantages to Keycloak:
Keycloak is also available with support if you buy JBoss EAP (see http://www.keycloak.org/support.html). This might be cheaper than the enterprise version of Auth0. If you want to use custom DB, you need enterprise version of Auth0 anyway.
Keycloak has features which are not available in Auth0:
Fine-grained permissions and role-based access control (RBAC) and attribute-based access control (ABAC) configurable via web admin console or custom code or you can write yuour own Java and JavaScript policies. This can be also implemented in Auth0 via user rules (custom JavaScript) or Authorization plugin(no code, less possibilities). In Keycloak you can do more without code (there are more types of security policies available out of the box e.g. based on role, groups, current time, an origin of the request) and there is a good support for custom developed access control modules. Here some more detailed research would be interesting to compare them.
Keycloak also offers a policy enforcer component - which you can connect to from your backend and verify whether the access token is sufficient to access a given resource. It works best with Java Web servers, or you can just deploy an extra Java Server with Keycloak adapter which will work as a gatekeeper and decide which request go through and which are blocked. All this happens based on the rules which you can configure via Keycloak web interface. I am not sure such policy enforcer is included in Auth0. On top of that, Keycloak can tell your client application which permissions you need when you want to access a given resource so you do not need to code this in your client. The workflow can be:
Client application wants to access resource R.
Client application asks Keycloak policy enforcer which permission it needs to access resource R.
Kecloak policy enforcer tells the client application which permission P it needs.
The client application requests an access token with permission P from Keycloak.
The client makes a request to the resource server with the access token containing permission P attached.
Policy enforcer which guards the resource server can ask Keycloak whether permission P is enough to access resource R.
When Keycloak approves, the resource can be accessed.
Thus, more can be centralized and configured in Keycloak. With this workflow, your client and resource server can outsource more security logic and code to Keycloak. In Auth0 you probably need to implement steps 2,3,6 on your own.
Both Auth0 and Keycloak should be able to achieve your goal - assuming you want only social (facebook, google etc), and /or username & password authentication?
Auth0 is the less risky option, keycloak is good for non-commercial & where you can afford production outages without a global 24x7 support team. Here a few other reasons why I'd recommend Auth0 - the documentation is world class, they have quickstart samples so you can get up and running in minutes, and easy access to more advanced options - passwordless, authentication, MFA, anomaly detection, x9's reliability, rate-limiting, an extensive management api, extensions for everything eg exporting logs to log aggregator, and so on. Anyhow, good luck with your project, and obviously what suits best may simply be down to your own project requirements.
Should add, if you are doing mobile, then Auth0 put a lot of effort into adding the necessary specialised security flows to target mobile (native / hybrid) apps. For instance, PKCE usage when using /authorize endpoint. Please bear that in mind, as not certain how keycloak has been implemented to handle this - alot of IDMs still do this incorrectly today.
I'm currently developing a API to commercialized in a B2B SAAS fashion.
The goal is to authenticate the worker of the company. We have an SDK that should be able to do that. There is the possibility to force each user to set credentials specific for our service, but that will hurt integration with companies applications.
The idea would be to have some kind of authentication (client independent) that make it easier to authenticate users.
The question is: There is a easy way to create an automatic process that does not depend on the client type of authentication methods, for this type of task?
Thanks in advance.
Have you taken a look at Azure AD? It specifically supports multi-tenant scenarios.
Tenants can use Azure AD Connect to sync their on-premise directory to the cloud. Clients can use ADAL to acquire a token which your service trusts. The issued token contains a tenant-id claim indicating via which tenant the user logged in.
Just to add to MvdD answer, in Azure AD support three ways to sign in:
Federated Single Sign-On enables applications to redirect to Azure AD
for user authentication instead of prompting for its own password.
This is supported for applications that support protocols such as SAML
2.0, WS-Federation, or OpenID Connect, and is the richest mode of single sign-on.
Password-based Single Sign-On enables secure application password
storage and replay using a web browser extension or mobile app. This
leverages the existing sign-in process provided by the application,
but enables an administrator to manage the passwords and does not
require the user to know the password.
Existing Single Sign-On enables Azure AD to leverage any existing
single sign-on that has been set up for the application, but enables
these applications to be linked to the Office 365 or Azure AD access
panel portals, and also enables additional reporting in Azure AD when
the applications are launched there.
I need to setup an environment where the client, resource owner server and authorization server communicate with each other using the standard OAuth2 APIs.
These are my requirements:
Usage of OAuth2 framework.
No TLS connections between client, resource owner and authorization server.
Usage of JWK/JWS/JWE/JWT technologies for security.
Ability to scale to large number of clients.
Is there a good strategy/open source projects available which already support this workflow?
If I need to write my own workflow, is there a good starting point?
My company is planning to host some applications on public cloud. For identity management in cloud, my understanding is that we have 3 options
Federation
Provisioning
Identity as a service
My understanding for federation is that any access to cloud based services, can be intercepted and pointed to identity provider within the organization, which will then perform authentication and authorization, provide a token and the application can inspect token and allow/disallow access
For provisioning, instead of identity provider being located within organization, it can be located in cloud and it can refer to identity stores in cloud, which are provisioned in batch or real time by standards such as SPML or SCIM
Is the above understanding correct?
An app being deployed to the cloud has little to do with identity federation or identity as a service. You could very well use Forms authentication on a cloud service.
The question is whether you want to make your app responsible for authenticating users or not. If you choose not to (which is likely a good thing), then you need to rely on a mechanism to outsource identity. The techniques to do this are referred to as "claims based identity", "identity federation", among others, and involve a number of protocols (e.g. SAML, SAML-P, WS-Federation, OAuth). These depend on the systems you want to use for authenticating users:
SAML/WS-Fed are typically used for enterprises (using AD for example)
OAuth is mostly used by consumer oriented systems (e.g. Facebook, etc).
So, depending on where your users are you might need to implement one or the other (or both).
Identity As a Service, means you use an external service provider to handle authentication with these providers for you. It is not a requirement and you could build this capability on your own.
Without details of your infrastructure and your app it is difficult to provide any guidance: ASP.NET? Java? nodejs?Azure? AWS? Heroku? Where are your users?