In corners cool, away from glare,
The Peace Lily thrives on tempered care.
Not blazing sun nor desert dry — 
She favors shade where shadows lie.

A drink she takes with quiet need,
But not so oft as thirst to plead.
Too much, and sorrow lines her face — 
With drooping leaves she marks disgrace.
Her roots, if drowned in love too deep,
Will fail to hold and cease to keep.

Yet leave her parched, and she shall bend,
A wilted form, as if to send
A gentle chide, a whispered moan:
“Neglect me not, though I’ve not grown
To ask in voice or clamor loud — 
I speak through leaf, not cries or crowd.”

Touch soil before the water flows,
Let dryness tell what she well knows.
A weekly sip may serve her well,
But listen close — she’ll always tell.

In filtered light, not harsh nor bold,
She stands in grace, not seeking gold.
With leaves of green and spathe of white,
She cleans the air and soothes the sight.

She needs no mists, nor fuss, nor frill — 
Just honest care and time to still.
A gentle cloth to dust each leaf,
Will bring her joy and grant relief.

So heed her form, both firm and fair,
And let her teach the art of care.
Not too much, and not too small — 
In balance lies the root of all.

Anxiety, a silent thief,
Steals my peace and brings me grief,
A constant shadow, always near,
Whispering doubts and filled with fear.

It grips my chest and twists my mind,
A prison, from which I cannot find,
A way to break these chains that bind,
And leave me trapped and confined.

But I will not let it win,
I'll fight the battle deep within,
For though it may be hard and long,
I'll find my strength and carry on.

For in the end, I know it's true,
That I am stronger than this too,
And though anxiety may try,
I'll rise above it, reaching for the sky.

Single sign-on (SSO) is a property of identity and access management (IAM) that enables users to securely authenticate with multiple applications and websites by logging in only once with just one set of credentials (username and password).

Here in this article, we will Implement Single Sign-On in a Node.js App with SAML authentication strategy using Passport.js middleware if you want to read more on Single Sign-on and SAML you can read this article below.

Single Sign-On(SSO) — SAML Authentication Explained

First, we need an Identity Provider which can be an organization’s active directory or any free identity provider like OneLogin. For testing purposes I used OneLogin identity provider it allows us to create a developer account and we can play around it https://developers.onelogin.com/

We can configure our App please follow documentation for more information.

We will configure this information from the SAML-Test connector into our Passport.js middleware.

This includes certificate, endpoint ie. entry point will be the entry point for our app this will redirect our app on the authentication page.

We need to configure our app information into the identity provider to establish trust.

Application details are all Service Provider’s configuration like issuer and consumer callback URL

Consumer URL we will configure Service Provider’s Callback Url which will be called on authentication success.

Above information provided by the identity provider which will set up trust between an identity provider and service provider. Here service provider will be a backend app that will make trust between multiple identity providers like Azure IDP, OneLogin, Google OAuth, and so on.

{
    entryPoint: 'https://ad.example.net/adfs/ls/',
    issuer: 'DEV-BrightLab',
    callbackUrl: 'https://your-app.example.net/login/callback',
    cert: 'MIICizCCAfQCCQCY8tKaMc0BMjANBgkqh ... W=='
 }

Here we have details which we will set up in our service provider to establish a trust between the service provider and identity provider.

entryPoint: is the URL provided by Identity Provider which will be used to redirect users on the login page if not authenticated.

issuer: is a string provided to the Identity Provider to uniquely identify Service Provider.

callbackUrl: This will be the URL of the Service Provider which will consume the SAML response once authentication is done on Identity Provider. Identity Provider will call this URL.

cert: This is the certificate provided by Identity Provider. This will be used to establish the trust between Identity Provider and Service Provider.

Now we are ready to implement our service provider using Passport.js

Passport is authentication middleware for Node.js. extremely flexible and modular, Passport can be unobtrusively dropped into any Express-based web application. A comprehensive set of strategies support authentication using a username and password, Facebook, Twitter, and more.

npm install passport

Install passport-saml, it is a SAML 2.0 authentication provider for Passport, the Node.js authentication library. The code was originally based on Michael Bosworth’s express-saml library.

npm install passport-saml

First We will Setup our passport handler middleware with our identity provider configuration. This is for a single identity provider strategy.

Now we can configure this Passport middleware into our app and initialize it.

• We will set up two routes one is the GET route which will be the entry point of SSO into the application. when it will be called passport will authenticate and verify the trust in between service provider and the identity provider.
• Another will be the consumer which will be called by the identity provider once it validated the credentials. Here Request body will be a SAML which is a base64 encoded body here I used the Saml2js module to parse the assertion in the SAML body which will provide the details of user who logged in.

Here is the router code for the Router

This is a user login controller which creates the session set in response cookies and redirect response to a UI Application page.

Let's put this all together and see how all this works…..

First, we call GET API localhost:9000/user/v1/users/login/sso

• This GET API call checks if the active session is there or not, In my case, there was no active session it redirects me on an identity provider login page.
• Once I entered my username and then password it authenticate request on identity provider and then it called the callback URL of service provider which we configured in the identity provider.

• This POST callback URL localhost:9000/user/v1/users/login/sso/callback created a session for the application by validating request and redirects to the application dashboard page.

Well, We have successfully configured SAML based Single Sign-On

What if we have a SAAS based multitenant application which has different organizations and we need to configure Single Sign-On with these organization's Active Directory or their identity provider, In this case, we can use Passport’s MultiSAML strategy where we can configure SAML configuration on demand, we can identify organizations by subdomain or we can pass path params to these above URL. Let's configure MultiSamlStrategy

Here getSamlOptions function will be invoked on passport.authenticate() middleware called here we are fetching SAML configuration from DB on the basis of request orgId and setting this config for this middleware.

Here we configure Routes with path params and also configured their value into identity provider.

He is how I configured my BrightLab application with my Organization’s Active Directory ie. Azure.

we provided callback URL as /login/sso/callback/orgNamehere orgName becomes the value for the path parm id and we fetch SAML configuration from DB by {orgId: orgName} and on calling login API it will be redirected to the meck azure login page.

On submitting id and password identity provider authenticates the request and calls the callback URL and Land on the dashboard Page. similarly, we can pass different org if we have configured it and stored it into our database and we can determine this on the basis on the subdomain as well.

If you want to implement multitenancy into the Node.js application you can read this article below.

Multitenant Node.js Application with mongoose (MongoDB)

References :

Documentation

Implement Single Sign-On SAML strategy with Node.js & Passport.js was originally published in TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is Single sign-on?

Single sign-on (SSO) is a property of identity and access management (IAM) that enables users to securely authenticate with multiple applications and websites by logging in only once with just one set of credentials (username and password).

This saves the user from remembering multiple usernames and passwords, while still providing strong authentication. And, once they have logged in, an end-user can access other connected web apps without logging in again, until their authenticated session expires.

How does SSO work?

Authentication with SSO relies on a trust relationship between domains (websites). With single sign-on, this is what happens when you try to log in to an app or website:

1. The website first checks to see whether you’ve already been authenticated by the SSO solution, in which case it gives you access to the site.
2. If you haven’t, it sends you to the SSO solution to log in.
3. You enter the single username/password that you use for corporate access.
4. The SSO solution requests authentication from the identity provider or authentication system that your company uses. It verifies your identity and notifies the SSO solution.
5. The SSO solution passes authentication data to the website and returns you to that site.
6. After login, the site passes authentication verification data with you as you move through the site to verify that you are authenticated each time you go to a new page.

In SSO, authentication verification data takes the form of tokens.

SSO Strategy

SAML is an XML-based open-standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider.

OAuth is an open protocol to allow secure authorization in a simple and standard method from web, mobile, and desktop applications.

What is SAML?

Security Assertion Markup Language (SAML) is a very powerful and flexible standard for logging users into applications based on their sessions in another context. This single sign-on (SSO) login standard has significant advantages over logging in using a username/password:

• No need to type in credentials
• No need to remember and renew passwords
• No weak passwords

Most organizations already know the identity of users because they are logged in to their Active Directory domain or intranet. It makes sense to use this information to log users into other applications, such as web-based applications, and one of the more elegant ways of doing this is by using SAML.

WHY USE SAML?

SAML is the gold standard for single sign-on for cloud apps. It eliminates all passwords and instead uses digital signatures to establish trust between the identity provider and the cloud app. Using SAML, users can seamlessly access multiple applications, allowing them to conduct business faster and more efficiently.

SSO also helps organizations to login employes to all the organization related applications with just a single username and password which can we associated with their system and the Active directory they are already managing and with SAML we can do Authorization and Authentication both.

For Example, we Integrated our BrightLab app with Organization’s Azure AD to login to the application with the same company’s email and they don’t have to log in if already logged in to any of the application associated with same AD ie. their Outlook any other App.

User requests access Flow

The website redirects the user to the SSO website to log in. The user logs in with a single username and password.

The SSO website verifies the user’s identity with an identity provider, such as Active Directory.

User is granted access and then requests access to a new site

When the user tries to access a different website, the new website checks with the SSO solution. Since the user has been authenticated, it verifies the user’s identity to the new website without requiring an additional login.

A Service Provider (SP) is the entity providing the service, typically in the form of an application.

An Identity Provider (IdP) is the entity providing the identities, including the ability to authenticate a user. The Identity Provider typically also contains the user profile: additional information about the user such as first name, last name, job code, phone number, address, and so on. Depending on the application, some service providers may require a very simple profile (username, email), while others may require a richer set of user data (job code, department, address, location, manager, and so on).

A SAML Request, also known as an authentication request, is generated by the Service Provider to “request” an authentication.

A SAML Response is generated by the Identity Provider. It contains the actual assertion of the authenticated user. In addition, a SAML Response may contain additional information, such as user profile information and group/role information, depending on what the Service Provider can support.

A Service Provider Initiated (SP-initiated) sign-in describes the SAML sign-in flow when initiated by the Service Provider. This is typically triggered when the end-user tries to access a resource or sign in directly on the Service Provider side, such as when the browser tries to access a protected resource on the Service Provider side.

An Identity Provider Initiated (IdP-initiated) sign-in describes the SAML sign-in flow initiated by the Identity Provider. Instead of the SAML flow being triggered by redirection from the Service Provider, in this flow, the Identity Provider initiates a SAML Response that is redirected to the Service Provider to assert the user’s identity.

SAML SSO Flow

The diagram below illustrates the single sign-on flow for service provider-initiated SSO, i.e. when an application triggers SSO.

Identity provider-initiated SSO is similar and consists of only the bottom half of the flow.

How SAML Works

SAML SSO works by transferring the user’s identity from one place (the identity provider) to another (the service provider). This is done through an exchange of digitally signed XML documents.

Consider the following scenario: A user is logged into a system that acts as an identity provider. The user wants to log in to a remote application, such as a support or accounting application (the service provider). The following happens:

1. The user accesses the remote application using a link on an intranet, a bookmark, or similar and the application loads.
2. The application identifies the user’s origin (by application subdomain, user IP address, or similar) and redirects the user back to the identity provider, asking for authentication. This is the authentication request.
3. The user either has an existing active browser session with the identity provider or establishes one by logging into the identity provider.
4. The identity provider builds the authentication response in the form of an XML-document containing the user’s username or email address, signs it using an X.509 certificate, and posts this information to the service provider.
5. The service provider, which already knows the identity provider and has a certificate fingerprint, retrieves the authentication response and validates it using the certificate fingerprint.
6. The identity of the user is established, and the user is provided with app access.

Implement SSO with Node.js

Implementation of SSO with SAML in Node.js using Passport.js middleware.

Implement Single Sign-On SAML strategy with Node.js & Passport.js

References :

How Does Single Sign-On (SSO) Work? | OneLogin

Single Sign-On(SSO) — SAML Authentication Explained was originally published in TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The term “software multi-tenancy” refers to a software architecture in which a single instance of software runs on a server and serves multiple tenants.

Architecting a multi-tenant system is more complicated than architecting a multi-user system. There are two models of architecting a multi-tenant system: Instance replication and Data-Segregation.

In the instance replication model, the system spins a new instance for every tenant. This is easier to start, but hard to scale. It becomes a nightmare when 100s of tenants signup.

In the data-segregation model, the application is shared between tenants but data of each tenant is stored in separate data stores. Separate data stores could be separate databases or separate schema within the same database.

Data Segregation is of two types

• One DB with different schemas for a different tenant.
• One DB per tenant.

separate schema ie. different tables within one DB for each tenant.

In this blog, we will discuss multitenancy with Data-Segregation Model with a single DB per tenant.

Create a Node app initialize one MongoDB connection along with the app and export this connection object. create this connection using mongoose createConnection as the createConnection method does not create default connection but return a DB connection object.

Here we are creating a MongoDB connection with mongoose and exporting it from here and it will be imported in config index.js file which will be initialized only once in the app and we can import this MongoDB object anywhere or we can also create and store it in global and can use it anywhere.

importing this MongoDB object and we can create a new MongoDB connection as per our tenant.

Mongoose provides useDb function which is used to create a new connection object it takes two params first one is DB name and another is options

Connection.prototype.useDb()

Parameters:
name      «String» The database name
{options} «Object» Configs

options = {useCache: false} «Boolean»  False by default

If set true, cache results so calling useDb() multiple times with the same name only creates 1 connection object.

Returns:
«Connection» New Connection Object

we are it switches to a different database using the same connection pool and Returns a new connection object, with the new DB, and using option {useCache: true} will create a single connection object for the same tenant if called multiple times.

To get the model from tenant DB, we need to create a schema of our model and pass it along with the tenant to this function, which will return a model. Now we can use this model to perform all of our crud operations.

In the Data access layer, we will first get the model as per our tenant DB connection and then perform crud operations. In each request, we have to pass tenantId and this tenantId will be used to switch with that tenant DB.

In this approach, we are using the same connection pool which we created at the time of app initialization. Multiple requests with different tenants will create different connection objects which will be timed out after 30 seconds if there is not new request with the same tenant.

There is another approach as well we can implement this will be helpful with limited no of tenants. In this, we can create a global object where the key will be tenantId/tenantName, and value will be the connection object. before every request we will check if the connection is there in this global object otherwise we will create a connection and store it there so in next request from that tenant will be reused.

In this above implementation, there can be a CPU usage issue if the number of the tenants will increase as the app will always have lots of open connection will degrade performance but it can be used in case you have fewer tenants and which will never grow dynamically.

Multitenant Node.js Application with mongoose (MongoDB) was originally published in TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.