Login issues with the portal are really frustrating

[ff...@nyu.edu]

My students are using Open ID login through the GENI portal to access the wireless testbeds at NYU and at WINLAB. We are experiencing an issue where we get stuck in a login loop and the Open ID authentication fails. Very occasionally, it works.

We had lots of issues with login loops when we first started using GENI in class this past Thursday. Practically everything we clicked on in the portal kicked us back to the login screen. It took anywhere from 4-10 tries each to do things like generate keys, join a project, etc. It was tremendously frustrating for everyone.

The Open ID issue has been happening ever since. It's also really, really, really frustrating.

This is a new issue that seems to have been caused by updates to the portal - as of the end of August, when I last tested this, Open ID was working flawlessly.

Thanks,

Fraida Fund

[Tom Mitchell]

Hi Fraida,

I'm sorry you had these challenges. I took a look at our logs from last Thursday and I see some curious things with respect to NYU logins. As you probably know, we use Shibboleth in front of the portal to enable access via InCommon. In Shibboleth's logs, I see logins from different IP addresses for a few NYU users, you included.

As an example, at 17:40:53 a new Shibboleth session was started for you from IP address X.Y.Z.77. At 17:40:59 (just 6 seconds later) a new session was started for you from IP address X.Y.Z.78. I see similar entries for others from NYU rapidly changing IP addresses. Here's another example for a different user:

17:37:17 from X.Y.Z.75
17:39:21 from X.Y.Z.76
17:39:36 from X.Y.Z.79
17:39:48 from X.Y.Z.70
17:40:00 from X.Y.Z.76
17:40:30 from X.Y.Z.72
17:40:45 from X.Y.Z.74

Shibboleth by default enforces a consistent IP address as a security measure. If a user presents credentials/assertions and the IP address doesn't match it voids that session and forces a new authentication. This matches the behavior you described. It appears that there is a Shibboleth setting that we can disable to allow varying IP addresses, but at a cost to security. I'd like to explore other options before choosing to make that sort of change.

Ivan had a similar issue in his lab that we discussed at the GEC last October. It was due to a certain kind of NAT or proxy device that uses a pool of IP addresses. Would it be possible for you to do a little research on your end about the use of pooled IP addresses? Could that be disabled when you are conducting a class? Is it possible that is a change at NYU since the last time you ran a class using the portal?

Thanks,
Tom

[ff...@nyu.edu]

Thanks for the response, Tom.

The IP address pooling thing does sound like a likely candidate, based on what you're seeing in your logs.

Unfortunately, the issue is not limited to in-class lab sessions. Students are using the wireless testbeds for homework and project work, and they need to use Open ID login to reserve testbed time. They are liable to be affected whenever they are on the NYU network, if it is indeed the pooling thing. 

Presumably the probability of this NAT/proxy thing being disabled all the time on the entire NYU campus is close to nil.

What else can we do to resolve this issue?

Thanks,

Fraida

[Tom Mitchell]

I agree that asking your IT folks to disable the pooling of IP addresses all the time on the entire campus is unlikely. I'm still curious if my theory about IP address pooling is correct. Does NYU actually do pooling of IP addresses? Or is it something else?

If there is IP address pooling it must have some associated parameters. For instance, the client's IP address couldn't be shifted on an SSH connection, could it? Perhaps they are pooling addresses for HTTP/HTTPS connections because they are presumed to be stateless? If that's the case, could there be a way for them to configure the pooling to use a consistent IP address when talking to certain servers? Or from certain client computers?

I think only your campus IT folks will know the the options available to you. Could you describe the problem to them and ask them what options exist?

We'll try to do some research on our end about whether the Shibboleth configuration option is likely to help in this situation, as well as the associated security risks.

Please let us know what you find out.

Thanks,
Tom