login context vs session

[Cantor, Scott]

On 4/9/13 11:47 AM, "Paul Hethmon" <paul.hethmon at clareitysecurity.com>
wrote:

>08:08:54.004 - DEBUG [com.clareity.shibboleth.db.SessionObjectDAOImpl:46]
>- [http-18780-3:] [1.2.3.4] [CD02440B9F5EEEFDF582B092A0554DBD] - No
>session object found, performing insert on [USERIDHERE].
>08:08:54.006 - DEBUG [com.clareity.shibboleth.db.SessionObjectDAOImpl:102]
>- [http-18780-3:] [1.2.3.4] [CD02440B9F5EEEFDF582B092A0554DBD] - New
>persistent session save to db [null]

Those lines at the end, don't they suggest that the initial attempt to
create the session in the store failed? Or did that fail because of the
null username?

>The 2 log lines showing:
>
>
>New persistent session save to db [null]
>
>Are showing the SessionManagerEntry object as my storage service gets it.
>The "null" is trying to get the principal value:

Isn't that code transitioning between the code calling the SessionManager
and your implementation of it? That would be server side code, not a round
trip back to the client and then looking up the session again.

The case that I was assuming was involved is when the IdP transitions the
user via redirect back from the authentication servlet to the profile
handler.

>So when it's passed to the storage service, something appears to be wrong
>with the object already, though later lines in the log file still show the
>principal name. When it gets to attribute resolution, it has the null
>value.

Right, but my point is it seems to be null even *before* that step. The
attribute resolution step happens in the profile handler, so the session
can be missing there and the only impact is that the user identity ends up
null. Everything else in the profile handler is driven off the login
context, except for that step, and that's where it all goes off track.

If I'm understanding your trace, it seems like there's a problem with the
actual calling into your session manager implementation. Of course, having
done that, it will be null later too, but the root cause seems to be
earlier.

>So maybe turn up to TRACE on the session code? Maybe authentication
>engine?

I think you're into adding logging territory to "printf" the user identity
in the exact spots it's calling into what ends up being your code.

-- Scott