VIDIZMO integration brief · ADFS · vidizmo.ai/integrations/catalog/adfs

Integrations / ADFS

ADFS

Sign users in with ADFS. Visit website

Active Directory Federation Services extends on-premises Active Directory to web applications, and remains common where the directory stays in the datacentre.

ADFS stays the identity provider and the platform never becomes one. Accounts, password policy and multi-factor stay where they are already governed, and access is removed by disabling the account there.

The Account Appears the First Time Someone Signs In

Open as a two-page brief

Active Directory Federation Services does one job. It is a role on a Windows server inside the organization's own network: it authenticates people against Active Directory and issues a signed token to a web application, and it provisions nothing, anywhere. That makes it the exception among identity integrations. With no SCIM feed to push accounts, a portal account is created the first time its owner signs in. Staff open Nexus with the domain account they already have, along with the Redactor, AI Intelligence Hub and AI Live Insight enabled on that portal.

How it connects

On the Windows side a relying party trust is added for the portal, and claim rules decide what it issues: name, email and the group claims the portal should see. On the portal side an administrator adds an SSO app under Admin, Portal Settings, Apps, labeled SAML / OIDC in the catalog, and enters the ADFS metadata address. Setup is documented. Where staff sign in from outside the network, they reach the same ADFS endpoint a Web Application Proxy already publishes, so nothing new is exposed.

Then the account creates itself. Someone opens the portal, is redirected to the organization's own sign-in page, authenticates against Active Directory and returns with the assertion. The portal creates their account at that moment, attribute mapping writes the claims into profile fields, and the SSO app's default Client Access License, the portal's bundle of features and permissions, entitles them at once. With group sync enabled, the group claims in that assertion categorize the user, resolved fresh at each sign-in, so moving someone between Active Directory groups takes effect the next time they sign in.

Two consequences follow from having no provisioning feed. Where an account must exist before its owner appears, because content is being shared with a named person in advance, users are added by hand or imported in bulk from CSV. And nothing pushes a departure into the portal: access ends because ADFS refuses to issue a token, force login leaves no local form to fall back to, and an administrator disables the portal record when the organization wants it cleared. Nothing is written back to Active Directory.

What you can do together

01

The domain credential is the only one

With force login set the portal keeps no sign-in form of its own, so whatever ADFS asks for at the organization's sign-in page, smartcard or security key, stands in front of Nexus and everything on it.

02

An account when it is needed, not before

No user list has to be imported to start. The directory decides who can get in, and the first sign-in does the rest.

03

One sign-in for four products

Redactor, AI Intelligence Hub and AI Live Insight are enabled on that portal, so one sign-in reaches all of them.

A scenario

  1. Monday, ITThe county's Windows administrator adds the relying party trust and writes the claim rules. The portal administrator adds the SSO app with the ADFS metadata address, maps the claims, sets the evidence viewer Client Access License as the default and forces login.
  2. Tuesday, 07:10A records clerk opens the portal for the first time. She is sent to the county sign-in page, taps her smartcard, and lands in the library with a profile she never filled in. Nobody created her account. Her first sign-in did.
  3. Same morningA detective asks AI Intelligence Hub which interviews mention a vehicle description, and gets an answer citing the recordings he is entitled to open.
  4. ThursdayA public records request arrives. The clerk opens Redactor, blurs bystanders' faces in a body camera clip and exports the copy. The original is untouched.
  5. FridayA deputy resigns and his domain account is disabled. ADFS will not issue him a token, force login leaves no other door, and IT disables his portal record that afternoon.

What stays where

Active Directory keeps the accounts

Creation, group membership, password policy, lockout and disablement are governed in the directory. The portal never becomes a second place where a person exists.

ADFS keeps federating everything else

It gains one relying party trust. Every other application it serves is untouched.

Nothing is written to the directory

The portal takes the assertion and the mapped claims at sign-in, and sends nothing back.

Deployment stays a separate question

The portal runs in your own datacenter beside ADFS, air-gapped, in a dedicated cloud, or as shared SaaS.

Products and solutions

Next step

See it on your own ADFS instance. We will show the connection made, the data moving and the output, then size it for your deployment.

Request a demonstration  or write to sales@vidizmo.ai

sales@vidizmo.ai  ·  vidizmo.ai/integrations/catalog/adfs

Not what you need?

We build it

Send us your API documentation and we build, test and maintain the connector, at no development cost to you.

Request this integration

Bring an MCP server

If the system publishes a Model Context Protocol server, AI Intelligence Hub connects to it as a client with configuration alone.

Define a REST endpoint

Describe your endpoint and it becomes a node in an agent workflow, without waiting on our roadmap.

Product names, logos and trademarks shown here are the property of their respective owners. Their use does not imply any affiliation with or endorsement by them.