Review and possibly remove CAS ticket dependency on IdPSession
Completed
Description fields
Basics
Logistics
Basics
Logistics
Description
There's a dependency in at least the GrantServiceTicket action on an IdPSession being present, in addition to and separately from, getting the authenticated principal name.
It's used only to populate the SessionId field in TicketState, but I can't find any evidence that gets used in an important way later, other than for logging.
I couldn't see any evidence of an actual call into the SessionResolver to fetch the session by the ID, which is the obvious thing it would have to be doing somewhere for it to be needed, but that may be somewhere in the code I just haven't hit yet.
My hope is that it's not needed, or at least can be optional or limited only to some cases such as proxying, so that use cases where the session layer in the IdP is turned off will still work. This is useful for protocol gateway proxying where authn is handled by something else, so you can avoid caching large amounts of user state in the gateway.
There's a dependency in at least the GrantServiceTicket action on an IdPSession being present, in addition to and separately from, getting the authenticated principal name.
It's used only to populate the SessionId field in TicketState, but I can't find any evidence that gets used in an important way later, other than for logging.
I couldn't see any evidence of an actual call into the SessionResolver to fetch the session by the ID, which is the obvious thing it would have to be doing somewhere for it to be needed, but that may be somewhere in the code I just haven't hit yet.
My hope is that it's not needed, or at least can be optional or limited only to some cases such as proxying, so that use cases where the session layer in the IdP is turned off will still work. This is useful for protocol gateway proxying where authn is handled by something else, so you can avoid caching large amounts of user state in the gateway.