## TL;DR
SAML sessions have lifetimes set by the identity provider, often shorter than a SOC shift, and portals that rely on them drop the agent back to the IdP mid-task. Design for renewal: detect the redirect to the identity provider, complete the approved re-authentication flow if the agent is permitted one, or hand off to a fresh session with state preserved. For shift-long work, agree a session policy with the identity team rather than fighting silent expiries daily.

```text
SAML SSO session expired mid-shift and the triage agent's soc portal login failed
```

## Use this when
- Portal actions start failing with SSO redirects partway through a shift.
- A fresh login works immediately, confirming session rather than account failure.

## Not for this skill when
- Nobody can log in through SAML at all. That is IdP configuration, an identity team incident.
- The agent account was disabled. Session renewal will not restore it.

## Steps
1. Confirm the pattern: log the time from login to first SSO failure across sessions. Verify: failures track the IdP session lifetime.
2. Check the portal and IdP session settings the identity team publishes for this application. Verify: the expected lifetime is known, not guessed.
3. Implement renewal handling: on SSO redirect during a task, pause, run the permitted re-authentication, and resume from saved task state. Verify: a forced expiry in a test session recovers.
4. If automated re-authentication is not permitted for this portal, restructure work into session-sized batches with clean handoffs. Verify: no batch exceeds the session lifetime.
5. Run a full shift-length triage simulation. Verify: work completes across at least one session renewal without lost items.

## Variant phrasings
### saml sso session expired soc portal agent login
The SAML expiry variant.
### portal session lifetime shift triage session renewal
The shift design variant.

Compatibility: SAML 2.0 SSO with common identity providers and SOC portal applications.

## Why it happens
Identity teams set session lifetimes for human risk patterns: a person notices a login page and re-authenticates in seconds. An agent notices nothing, so a policy tuned for humans becomes a reliability bug for automation unless the design accounts for it.

## Edge cases / pitfalls
- Risk-based policies may demand interactive steps an agent cannot perform. Negotiate a service session explicitly rather than bypassing controls.
- Session renewal events belong in the audit log; silent renewal looks like session sharing.
- Align agent shift schedules with session lifetimes when planning unattended runs.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_FXFbqYsIW-mkrxn_m-3Zuw