The purpose of this blog is to explain and demonstrate bridging of saml to openid auth flows.
The requirement arises through the need of enabling applications which natively support openid but the IDP is only SAML compatible. This becomes a challenge when implementing Single Sign On auth, and due to regulatory needs we can have one source of truth, for user auth across the organisation. No native auth flow or user collection must be build scoped within the app to bypass the SSO.

Though due to limitation of only SAML support, we cannot straight away implement such SSO auth flows.

One way of doing this is a broker/bridge mechanism.

Overview

• SAML to OIDC Bridge is layering an IDP over another.

• The Bridge acts as both IDP and SP to delegate and translate auth flow cross protocol.

• On the IDP end it serves OIDC/Oauth2 protocol.

• On the SP end it used SAML Client

• The Bridge is configured with OIDC Auth Details.

• The OpenID client id and client key is used by app to authenticate with bridge oidc provider.

• The OIDC provider uses PKCE to secure the client auth in additional to client id and secret.

• It ensures that the client using the user tokens is the same as the one that has requested them.

Flow:

• The a user on client app asks for login.

• They are redirected to SAML IDP selection on bridge.

• Upon Selection they authenticate with IDP.

• On successful authentication SAML Assertion callback is made.

• Bridge then inform the OIDC Provider component to issue correspondig openid credentials.

• Using the openid tokens user is authenticated and authorized to access the requested resource.

Setup:

For demonstration we’ll be using a oidcdebugger.com as client service, and setup a bridge on local with a SAML IDP using Okta.

Execute the commands as follows:

git clone https://codeberg.org/drpdishant/k8s-lab.git 
cd k8s-lab/saml2-oidc docker-compose up -d 
# This serves the bridge at https://saml2oidc.127.0.0.1.nip.io

# The endpoints are preconfigured in Okta to work with.

Openid config endpoint will be https://saml2oidc.127.0.0.1.nip.io/.well-known/openid-configuration

Check config.json for SAML SP and OpenID Provider config.

This one has an oidc client configured with following params:

{
    "client_id": "some-client-id",
    "client_secret": "client-secret",
    "redirect_uris": [
        "https://oidcdebugger.com/debug"
    ],
    "allowedOrigins": [
        "https://oidcdebugger.com"
    ],
    "token_endpoint_auth_method": "none"
}

Use these to configure client at https://oidcdebugger.com/

Usage:

• Open oidcdebugger.com

• Configure The params as follows:

  • Authorize URI: https://saml2oidc.127.0.0.1.nip.io/auth

  • Redirect URI: https://oidcdebugger.com/debug

  • Client ID: some-client-id

  • Scope: openid

  • Response type: code

  • Use PKCE?: checked (SHA256)

    • Token URI: https://saml2oidc.127.0.0.1.nip.io/token

  • Response mode: form_post

• Send Request

• You’ll be prompted to choose the IDP.

• Choose the IDP and you’ll be sent to Okta Login Page.

• Enter the following credentials:

  • Username: john.wick@boogeyman.com

  • Password: Overhung1-Celtic0-Driver3-Activate0

• Upon Successful login you’ll be redirected to debug page.

Sadly it has come to this that the sysadmins of cloud era have been boasting their knowledge of cloud services but lacking the fundamental understanding of Linux, and how operating systems function. All due to fast paced learning and FOMO, they have been missing out important aspects of running servers and maintaining them reliably. Another factor recently observed is heavy reliance on AI tools to seek quick answers. With that said lets being with actually discussing the title.

What is nohup?

As the definition on Wikipedia says, nohup is a POSIX command which means "no hang up". Its purpose is to execute a command such that it ignores the HUP (hangup) signal and therefore does not stop when the user logs out.

It is usually helpful for admins to run ad-hoc background tasks across SSH sessions, or on their workstations, so that they don't have to worry about exiting the process upon accidental termination of sessions. ad-hoc background tasks are usually once in a while jobs that won't be repeated and don't require any availability or reliability, nohup only helps admins to run such tasks in background for time being to increase their productivity and perform many such tasks in parallel which don't require constant monitoring.

Some examples of such tasks are:

• syncing a large filesystem, object storages

• one off database migrations

• debugging services

• temporary webhooks

$ nohup s3 sync s3://large-bucket-old s3://large-bucket-new &
$ exit

What is systemd?

As the definition on Wikipedia says, systemd is a software suite that provides an array of system components for Linux operating systems. Its main aim is to unify service configuration and behavior across Linux distributions; Its primary component is a "system and service manager"—an init system used to bootstrap user space and manage user processes.

systemd has been integral part of many linux distributions as in init system and is at the root of process management that serves user experience for server and desktop users. Its a daemon that manages other daemons.

In multitasking computer operating systems, a daemon is a computer program that runs as a background process, rather than being under the direct control of an interactive user.

Using systemd you can not only configure your applications services as daemon processes, but also configure the sequence they start up, you can define dependencies, on other processes e.g an app process starting up after database.

Along with dependency on other systemd managed processes you can also define target you want your process to start into.

systemd targets are different states that your system can boot into, comparable to System V runlevels.

Systemd Unit file for nginx webserver.

[Unit]
Description=The NGINX HTTP and reverse proxy server
After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target

The common configuration items are configured in the generic [Unit] and [Install] sections.

complete list of options available can be found in systemd man pages, by running man systemd.unit and man systemd.install respectively

The service specific configuration options are configured in the [Service] section.

Complete list of Service section options can be found by running man systemd.service

If you have observed almost any standard service you install on a linux server configures a systemd service unit file, because its the standard way of doing it. Though all of it is scripted and packaged to be installed by your package manager most of the time and you don't have to configure it yourself , it doesn't mean that you can't configure systemd for your own application services. You can use it to run your web apps built in java, python, nodejs etc. Anything you want to be running in background and orchestrate its start-up across system reboots, systemd is best way to do that.

Closing Note:

Although we have been talking about systemd all this time, its not only init system out there but a popular and default for many OSes, and what you can achieve with systemd can be achieved with other init systems also. Some of these are SysV, openrc, upstart etc.

Conclusion:

nohup, although being a quick and easy way to run background task, is ineffective for long running services in production, such as databases, application servers, webservers, etc, while systemd is at core of process management in multitasking linux operating systems and preferable way to run apps and web servers as daemon processes in Linux, in production.

References:

• https://documentation.suse.com/smart/systems-management/html/reference-managing-systemd-targets-systemctl/index.html

• https://www.shellhacks.com/systemd-service-file-example/

• https://www.slant.co/topics/4663/~linux-init-systems