OneLoginIdentity and Access
Directory-Driven Access Without an Identity Program
Two or three people usually run IT in a OneLogin shop. They also run the help desk, the network and the application list, and they picked an identity provider priced and administered for an organization that size, because what they needed was single sign-on and directory-driven access rather than an identity program with a team behind it. Connecting Nexus is sized for that: an application on one side, an SSO app on the other, and a user list that fills itself. Redactor, AI Intelligence Hub and AI Live Insight are enabled on the same portal and need no further setup.
What you can do together
One less password to reset
With force login set, OneLogin is the only way in and the portal has no local sign-in form, so portal password resets stop reaching the help desk.
A user list that fills itself
SCIM creates, updates and deactivates accounts from the directory, which removes the spreadsheet import that a small team otherwise repeats every intake.
Access set once, by group
A rule on the group's display name decides which Client Access License someone holds, so a role change upstream reaches the portal by itself.
Four products, one setup
Nexus and the Redactor, AI Intelligence Hub and AI Live Insight enabled on it are covered by the one SSO app and the one provisioning feed.
The assistant respects those same groups
AI Intelligence Hub runs retrieval under the person asking, so somebody who cannot open a board recording cannot have it summarized either.
How it connects
The portal side is short. An administrator adds an SSO app under Admin, Portal Settings, Apps, labeled SAML / OIDC in the catalog, and enters OneLogin's metadata address or a client id and secret. Attribute mapping pairs OneLogin attributes with profile fields, and the app carries the default Client Access License, the portal's bundle of features and permissions, that anyone arriving through OneLogin receives. OneLogin has a documented setup guide, and both sides are entered through admin screens.
Provisioning is the second piece, with the portal as the SCIM 2.0 service provider. Enable provisioning, generate a portal-scoped API token with an expiry, and give OneLogin that token and the base URI. Users and groups then arrive ahead of first use, and rules override the default by matching the incoming group's display name.
Three practical notes matter more to a small team than to a large one. Rule order decides the outcome where somebody's groups match more than one rule, so put the narrowest rule first. A large group provisioned against several rules takes longer to process, which is worth knowing before a first sync at term start. And the API token expires, so it needs a calendar reminder, because nobody else is watching for it.
OneLoginIdentity and Access
A scenario
- JulyAn administrator adds the portal as an application in OneLogin and the SSO app in Nexus, maps name, email and campus, enables SCIM and pastes the token in. Rules: Faculty to the instructor Client Access License, Safety to the reviewer level, everyone else to the viewer default.
- Same weekThe directory pushes across. Faculty, Safety and everybody else arrive with their campus already on the profile, entitled on arrival, and nobody imports a spreadsheet.
- First staff day, 07:30A new instructor signs in through OneLogin with her authenticator code and finds her department's recordings already open to her.
- SeptemberThe safety coordinator reviews an AI Live Insight alert from a campus entrance, then uses Redactor to blur other students before a clip goes to a parent.
- DecemberAn instructor resigns and HR disables the OneLogin account. The portal account deactivates with it, and there is no second system for the administrators to remember.
What stays where
OneLogin remains the identity provider
Passwords, factors and the account lifecycle are governed there, and the portal never becomes a second user directory to maintain.
Setup is configuration, not a project
Two connections, one for sign-in and one for provisioning, each with a documented guide.
Traffic runs one way
Claims arrive at sign-in and SCIM pushes users and groups in. Nothing is written to OneLogin, and the password never reaches the portal.
Where the portal runs is your choice
Shared SaaS, a dedicated cloud, or your own datacenter at an address OneLogin can reach for provisioning.
Products and solutions
Next step
See it on your own OneLogin instance.
We will show the connection made, the data moving and the output, then size it for your deployment.
Contact VIDIZMO
sales@vidizmo.ai
+1 571-969-2180
vidizmo.ai