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?
Related
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.
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.
We have a Mulesoft Cloudhub environment which we are planning to deploy public APIs and we also have a VPC configured where we will deploy private APIs.
I'm looking at how best to secure the APIs and seen the following approaches:
Basic Authentication
Client Id and secret
OAuth
LDAP
SAML
My query is when should you use each one? Are their example use cases? E.g. OAuth seems to be more secure than basic authentication and client id and secret so why not use OAuth all the time and forget about the other two?
Thanks
OAuth is geared more towards authorisation rather than just authentication.
For example OAuth 2 has many different flows geared towards different use-cases. Such as 3 legged OAuth allowing you to use an external identity provider allow users to be authorised to access your resources. In a way, you’re not performing any authentication at all.
Http basic can still have a purpose in simple scenarios MAYBE when the cost and/or effort of using something else is not worth it and it’s internal network and the OJ already have some sort of ldap or active directory type thing is use for other apps (and using SSL is very important here as basic auth credentials are plain text)
For client id and secret, although it is similar to username/password, it’s more in the semantics - you are trusting a client rather than a person with the credentials.
For example, you can use client id to authenticate actual clients like a mobile application or a web app. Client id implementation like MuleSoft’s API Manager also allow you to add policies such as rate limiting and SLA based rate limiting so you can limit specific client applications to not overload your API.
You could use it alongside OAuth. Client ID/Secret for accessing the API but OAuth for authorising the end-user .
Here is a more detailed article discussing the pros and cons of the various common api auth mechanisms and a link to choosing between the various OAuth flows for your use-case.
https://nordicapis.com/3-common-methods-api-authentication-explained/
https://auth0.com/docs/api-auth/which-oauth-flow-to-use
I'm starting to write a few microservices that will have independent web clients, a centralized authentication and authorization service, and an organization service. The organization service will keep track of who belongs to what organization and what that organization has paid for. This will tell me who can access which web client and what parts of each individual microservice. I've only developed authentication using Devise in a single Rails monolith, so I'm exploring how to do it in a multi microservice and web client ecosystem. I've come up with this:
Web Client makes a request to a microservice and is denied because lack of session information sent in the request.
Web Client makes a login request to the Authentication service. The Authentication makes a request to the Organization service to see what organizations the user is a part of as well as the services paid for. The session info is stored in the Web Client for future use in requests.
Web Client makes a request to the Microservice. The Microservice validates the session information (from 2) against the Authentication service, which in turn reaches out to the Organization for the user's organizations and the organization's services. The response from Authentication is stored in the Microservice. The response back to the Web Client is granted if the two sets of session information match.
Web Client makes a request to the Microservice, including the session info (from 2). The Microservice validates the session info against the stored session info (from 3). The response back to the Web Client is granted if the two sets of session information match.
Is this the proper way to authenticate? Is there a better way to do it? Are there small tweaks I should make?
Additionally, should I treat Authentication from the Web Client to the Microservices differently than Authentication between Microservices?
Do yourself a huge favor, and don't try to invent this yourself. Many, many people have written a fully functional auth & auth system, and a few of them have done it right. Unless you are a security specialist (which you likely aren't if you are asking this question), use a framework.
Start by looking at OAuth 2.0 and OpenId Connect providers, it is the de-facto standard in distributed authentication. Whichever language/platform you are using, likely has an implementation that you can leverage out-of-the-box. This will dramatically speed you up, and will likely avoid all the things that you will be doing wrong in your implementation.
Here you are, ready out of the box, Identity Server based on Open ID and Auth2.0 that is all what you need.
welcome-to-identityserver4
If you were interested in the topic of Microservices Architecture the following links are a set of articles that published about microservices in code-project, you can read and comment on your questions if you like.
https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-I
https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-II
https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-III
I am working on a security component to use with an ESB for a client with very concrete high level requirements:
Integrate into an existing IWay service manager version 5.5 ESB (there is no security system in the existing set up).
Provide authentication and authorisation level information from source data stored in an existing active directory server used for another system (preferably using LDAP).
Authentication and authorisation should be performed in the ESB as the interface for the ESB will be exposed to both internal and external clients so total control over the client is not possible.
The client can not be relied up to have a certificate to allow bilateral SSL authentication, however unilateral authentication, where the client checks to see he is hitting the correct server is possible, so HTTPS connections can be established.
The service should sit on Weblogic (but I will be happy to take suggestions regardless)
Further information:
IWay ESB is a commercial, closed and fairly poor solution, in version 5.5 it provides no out of the box solution which fits the requirements. it is also stateless so no sessions can be maintained other than using a cookie or some method similar to store information.
Current ideas:
To implement a SSO service that is added to the messaging bus which provides a identity provider, service provider functionality, so an initial authentication will provide a token, which can then be stored by the client and passed with each subsequent request to be authenticated and an authorisation level passed (which i believe to be a fairly standard design pattern).
Research has been carried out on SSO + SAML implementation, openAM, Shibboleth, CAS all seem to provide a too complete solution which caters more for a portal type architecture (like CAS) or from a system where the initial SAML identity token is received from another sever altogether and then brought to the system (like googles implementation of SAML for some of its services).
I have also looked into JBossESB, openESB and service mix solutions which seem to use a bespoke implementation of SAML which can't be ported onto Weblogic and Zxid which has limited documentation.
It is a complex undertaking so I am expecting more high level architectural styles and library/project suggestions rather than complete solutions. I am under the impression that this should be a reasonably common requirement, a authentication and authorisation service for a ESB which uses a token system to prevent credentials having to be continually entered or stored in plain text but I am unable to find much information, what am I missing?
Any further questions I would be more than happy to elaborate.
It seems a solution using SAML is a valid solution for when users potentially/do require to access a third party service on an ESB but don't want the third party service to be aware of the security specifics of the ESB and the credentials information of the user. This way the ESB may provide a SAML token provider where the user can get the ticket and transport it to different services for authentication, the services then check back with the token for authentication and possible authorisation information (with SAML2 only). In addition to this SAML could be used like open ID where users are managed externally and users go to the external token provider to get SAML tickets.
This was a valid solution for us as the the client wanted to be very aware of the users accessing the ESB and there was to be no plan to access third party services as it was a completely closed system.
We subsequently implemented a more custom SAAS (security as a service) mechanism for internal authentication and authorisation inside the ESB (I know it sounds bad but with iWay there are limited options) using spring security libraries and the remember me functionality which in our case met the requirements.
Low and behold our clients then changed their requirements and asked for integration with share point. This did however simplify the security model in our system because we then designed of the following:
iWay's primary security model is based around SSL certificates, it is possible to implement an SSL Provider which will manage certificates, you should therefore be able to supply share point with your SSL certificate and iWay with the public certificate and secure up the channels between the 2 servers, you can then manage users within iWay who can access the ESB on a system level and specify a share point user even specifying it's ip, this information is sent in plain text but over SSL and in our case sent between servers in the same network.
We are then leaving it to share point to authenticate users on a finer level so access to applications is managed at the share point 'portal' level and the only thing the ESB is vaguely aware of is the authorisation information which is passed with the client SOAP message and defines to what level the services can be accessed (this information is used on a service level).
Downsides to this solution are:
For each new client application developed to access the ESB interfaces a new ESB user must be configured so it is not possible for clients to be developed which can freely consume certain services on the ESB.
New clients have to implement the authorisation logic so the correctly formated authorisation string can be sent and understood by services.
Other points:
I am aware that the newer version of iWay provides a LDAP adaptor which should be able to communicate with AD so you can have your LDAP server attached to the ESB through this way so it could possibly be consumed by another client or services in the ESB but you would have to customise share point to access the information through the iWay business provider.
I also believe iWay 6 provides a SAML token provider which you could utilize (going back to what I said previous about the use of SAML) but I don't believe this fits in with a share point solution.
I would like to share more ideas seen as we are both doing the same thing, can you find me through my twitter account which is specified in my blog?
We are currently working with iWay Server Manager 6.0.1 and are also having difficulties identifying HOW to handle security for web services within this tool.
We want to build web services with it that have AD security in them like if we were using .NET Web Services and haven't found a solution. Even discussing this with the iWay staff did not clear it in our minds.
Now we have to connect to SharePoint web services and the issue will definitely be there.
Have you progressed with your situation? We would like some feedback from people using the tool on how they actually implement security with iWay.
Sorry for the delay... been quite busy over here...
Basically we've done many tests between iWay and SharePoint and we are not able to set it up to sent the NTLM credentials required by SharePoint. We've tried setting up channels, proxies and various other solutions within the tool...
We've placed a call to them to hopefully get some help...
Pascal