3

Before I log in I can hit anything outside of my security constraint directory. If I try to go to a location inside of the security constraint directory it redirects me to the form login page. As you would expect.

Once logged in I can go about my business, and hit resources both outside and inside my security constraint.

But, when the LTPA token expires (Still have an active session) and I try to go to a unrestricted page, lets say like being redirected to the login page, I get the error in the title.

So a few things I would like to figure out: 1. Can I get the LTPA token to not expire like my session? 2. Can I expire my session when the LTPA token does? 3. Why can't I hit an unrestricted page anonymously? It's clearly recognizing that my LTPA token has expired and tries to redirect me to login. At which point it fails.

OK, So got somewhere with a filter. The filter redirects someone who isn't logged in to the login page. But the problem again is as soon as the ltpa token is expired this line fails ((HttpServletRequest) request).getSession(false) throwing the exception in the title, UnauthorizedSessionRequestException. So as you can see I tried to catch that error and do a log out. Which, woops, throws another UnauthorizedSessionRequestException. So how am I to not use the session?

@Override
public void doFilter(final ServletRequest request, final ServletResponse response,
    final FilterChain chain) throws IOException, ServletException
{
    final String sourceMethod = "doFilter";
    if (logger.isLoggable(Level.FINER)) {
        logger.entering(sourceClass, sourceMethod, new Object[] { request, response, chain });
    }

    try {
        final HttpSession session = ((HttpServletRequest) request).getSession(false);
        final UserBean user = (session != null) ? (UserBean) session.getAttribute("userBean")
            : null;
        if (user == null || (user != null && !user.isLoggedOn())) {
            final HttpServletResponse res = (HttpServletResponse) response;
            res.sendRedirect("../login.jsf");
        } 
    } catch (final UnauthorizedSessionRequestException exc) {
        ((HttpServletRequest) request).logout();
        final HttpServletResponse res = (HttpServletResponse) response;
        res.sendRedirect("../login.jsf");
    } catch (final Exception exc) {
        final ServletException exception = new ServletException(
            "[UserBeanFilter] Exception doFilter.", exc);
        logger.throwing(sourceClass, sourceMethod, exception);
        throw exception;
    }
    chain.doFilter(request, response);
    logger.exiting(sourceClass, sourceMethod);
}
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
Justin Brew
  • 33
  • 1
  • 5
  • How is this jsf related? Your question does not show any relation to it – Kukeltje Oct 21 '15 at 11:16
  • It's a JSF application, I thought that was pertinent information. – Justin Brew Oct 21 '15 at 14:38
  • It's pertinent if it is relevant to the problem. You could as well add 'java', 'energy', 'global-warming' (caused by buring fossil fuel needed for the energy to run java ;-)). Please remove it – Kukeltje Oct 21 '15 at 14:41
  • 1
    I disagree. JSF implies 'java', 'energy', 'global-warming' (caused by buring fossil fuel needed for the energy to run java ;-)). Websphere-8 and LTPA do not imply what type of application we are trying to run on that platform in which we are seeing the error. – Justin Brew Oct 21 '15 at 15:11
  • I was exaggerating a little. The point is that nothing in your post points to this problem being jsf related, not even one line of jsf code. The fact that you use jsf is not a valid reason to add that tag. That is why I referred to java (you are also using that but that tag is even more invalid), energy (you are using that right?). Does it fail with a simple jsp to? Please read [ask] about tagging – Kukeltje Oct 21 '15 at 15:20
  • Thank you for your response. I have looked up how to tag and found this "Try to include a tag for the language, library, and specific API your question relates to." This could likely be a root cause of how JSF handles sessions. As in it always creates a session. Unlike JSP which apparently from Gas' response I could do something like <@page session="false"> – Justin Brew Oct 21 '15 at 15:27
  • JSF is not a security framework. It's a MVC framework. – BalusC Oct 21 '15 at 19:46
  • @BalusC I think it's a bit how JSF is handling Sessions/Security. And you can't say that JSF has nothing to do with security. Removing JSF and putting java-ee could possibly get me the wrong answer. Like someone telling me how to handle this problem in JSP which wouldn't help me. – Justin Brew Oct 21 '15 at 20:44
  • Sessions aren't managed by JSF but by Java EE container (Websphere in your case). There's no [jsp] tag so you're safe ;) – BalusC Oct 22 '15 at 06:30
  • @BalusC yes the session is managed by the container but doesn't every JSF page access a session? I get the same error on a simple "Hello World" xhtml page. It's not just something weird I'm doing at the login page. See the problem now? I can't get to my login page because it uses a session and is giving me an error saying I'm trying to use my old session, is that not a problem in some part with JSF? And therefore there could be some solution in JSF. Other than what IBM is telling me to do which is turn off security integration, which means anonymous access to a session is ok... – Justin Brew Oct 22 '15 at 13:54
  • You'd have had exactly same problem with any other MVC framework using the same authentication mechanism, even with plain JSP. None of this all involves any class of `javax.faces.*` package. So, not a JSF specific problem. – BalusC Oct 22 '15 at 14:38
  • @BalusC But I am using JSF and even though it isn't a JSF specific problem, there may be a JSF specific solution. In regards to JSP Gas seems to think adding the tag to a JSP could get around this issue. And to JSF maybe this? http://stackoverflow.com/questions/4095713/no-session-generation-in-jsf. That's been my entire point. But no, you don't want it in the tag. Fine, I'm done arguing. The tag has been removed and Gas has been far more helpful than you or Kukeltje fussing over a tag. – Justin Brew Oct 22 '15 at 19:51
  • Authentication takes place before JSF runs. I didn't fuss about a tag, you did. – BalusC Oct 22 '15 at 19:51
  • Right you didn't fuss about it, you flat out removed it from my post. Thanks! – Justin Brew Oct 22 '15 at 19:53

2 Answers2

3

Can I get the LTPA token to not expire like my session?

Unfortunately no. LTPA token has fixed timeout, and session has inactivity timeout. If you need you may extend LTPA token timeout for example to 8 hours to avoid expiration.

Why can't I hit an unrestricted page anonymously?

Because it tries to access session which was previously associated with authenticated user. You can allow anonymous access to session by disabling Security integration setting in Servers > Server Types > WebSphere application servers > server_name > Session management.

You can also check if Use available authentication data when an unprotected URI is accessed is enabled in Security > Global security > Authentication > Web and SIP security > General settings.

It's clearly recognizing that my LTPA token has expired and tries to redirect me to login. At which point it fails.

Try to disable session support on your login page, if it is jsp then try to set <@page session="false"> in the page.

UPDATE

So if you want to be preventive, you can check the LTPA expiration, and based on that logout user before token expires, for example 5 min before. Of course, if user will be inactive for that 5 min, you will still get that exception, but it should be sufficient for 90% of cases.

To get expiration of the token use the following code (pseudo code):

WSSubject subject = WSSubject.getRunAsSubject();
Set<WSCredential> credentials = subject.getPublicCredentials(WSCredential.class);

for(WSCredential credential : credentials) {
     // in the most cases you will find only one credential, but if you 
     // want to be sure you can check credential OID
        System.out.println("Exp date:" + new Date(credential.getExpiration()));
        System.out.println("userName: " + credential.getSecurityName());
        System.out.println("cred: " + credential.getOID());

        // if expiration date closer than your threshold - logout user
        // ... 

}



OIDs for auth mechanisms

BasicAuth (GSSUP):  oid:2.23.130.1.1.1
KRB5: OID: 1.2.840.113554.1.2.2
LTPA:    oid:1.3.18.0.2.30.2 

UPDATE 2

Ok, I found nicer solution for you.

Just set the following flag in session manager:

InvalidateOnUnauthorizedSessionRequestException=true

InvalidateOnUnauthorizedSessionRequestException

Set this property to true if, in response to an unauthorized request, you want the session manager to invalidate a session instead of issuing an UnauthorizedSessionRequestException error message.

When a session is invalidated, the requester can create a new session, but does not have access to any of the previously saved session data. This invalidation allows a single user to continue processing requests after a logout while still protecting session data.

See details in here Session management custom properties

Gas
  • 17,601
  • 4
  • 46
  • 93
  • 1. I was hoping there was a way to programmatically regenerate the LTPA token without having the user re log in. And extending the timeout on a cluster with other business apps will be troublesome. 2. I'd rather not open up anonymous access to sessions. And the second option is enabled. If disabled I get SECJ0369E: Authentication failed when using LTPA. The exception is com.ibm.websphere.wim.exception.WIMException. Which I assume is because the login page post isn't getting the authentication information anymore. 3. I'm using JSF 2.2. I'm not finding an option like this that is equivalent. – Justin Brew Oct 21 '15 at 14:33
  • Also, thank you for your response. I also tried adding a filter to the site which would invalidate the session on the login page. But it looks like the filter isn't getting invoked before I get the error. – Justin Brew Oct 21 '15 at 14:40
  • I tried some more with a filter and hit a dead end. See the updated original post. – Justin Brew Oct 21 '15 at 18:17
  • The last option works great. I also came to find that the our environments have the security integration disabled. So what happens is my logs get filled with thousands of the LTPA Token has expired warnings. To counter that I could just have a filter login if the authtype is null. But that would mean having to save the username and password in session... This all would be fixed if IBM treated the LTPA timeout like a session timeout, based on last access. – Justin Brew Oct 22 '15 at 19:42
  • Link is not working.Check : https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.0.0/com.ibm.websphere.nd.doc/info/ae/ae/rprs_custom_properties.html#invalidateonunauthorizedsessionrequestexception – Chinmoy Jan 01 '18 at 13:21
0

For Webshepre 8.5 . Go to Servers > Server Types > WebSphere application servers > server_name(server1) > Session management.(look on the right side menu) Custom Properties -> Add new properties

Name =InvalidateOnUnauthorizedSessionRequestException
Value=true.

Save it and restart the server in eclipse. I faced this issue while testing webservice in SOAPUI.

Chinmoy
  • 1,391
  • 13
  • 14