What are you trying to achieve ? Does it really have to be in the session ? With the former portal how do you share the information in the different sessions ?
If you look at the 2.6 codebase, we use a different approach. An identity service is sitting waiting for your portlets to ask information about the user. After all the only thing you need to propagate is the username, from that you can get any information you want using those services.
You can get the username using the JSR168 API
We have many processes that run before any portlets are instantiated. The docs seem to elude that injecting services may be the answer to my question. An example would be a user logs in based on his credentials a call to a legacy app returns a list of patients that the user has a relationship to. This list would be in our proprietary Context(session) so no matter what portlet he was using that list would be there. It can't be in a portlet because we don't know which portlet he may have on his default page. Other processes include sharedsession(CCOW), our proprietary auditing, any thing required to set up the session for that user.