<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 4/18/16 2:27 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE1128BB3D6@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<blockquote type="cite">
<pre wrap="">Questions:
1) Does anyone know how/why this could happen? Is IDP3 less likely to
repeat this problem?
</pre>
</blockquote>
<pre wrap="">
V2 loads the metadata into memory in object form and then writes it back into XML when the servlet runs. </pre>
</blockquote>
<br>
I had to look. It actually loads the file into a full
FilesystemMetadataProvider, and so that's going to do refreshing and
all that stuff. So perhaps something there is going awry. Without
any logging, however, I don't know what. Looking at the code,
nothing jumps out at me that might do something as described.<br>
<br>
Are you absolutely sure the file on disk wasn't touched at any
point? Because of the filesystem metadata provider behavior, if a
newer one was swapped in, it would eventually load that. Then if
the original, older file was swapped back in, with the original
older last modified timestamp in place, I believe it would never
reload that (except on a restart) because the file timestamp would
be older than the most recently loaded one in memory. That's the
only thing I can currently see that is consistent with what you
described.<br>
<br>
<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE1128BB3D6@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<blockquote type="cite">
<pre wrap="">2) Could this be the result of a hack? Would such metadata changes affect
the security of the idp, besides being a denial of service?
</pre>
</blockquote>
<pre wrap="">
The metadata changing is irrelevant, what's relevant is that something modified the objects in memory, apparently. That would mean all bets are off.
That's a pretty weird thing for somebody to do if they had access to the JVM. Nobody trying to steal the key is going to leave footprints that silly. I'm sure there's a more innocent explanation but I can't imagine what it would be.</pre>
</blockquote>
<br>
I can't either really. Nothing comes to mind off-hand, other than
the above. Seems like a very odd issue. <br>
<br>
<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE1128BB3D6@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<pre wrap=""> Maybe a low memory condition of some kind.
</pre>
</blockquote>
<br>
<br>
Maybe, but I can't understand how it could just remove the endpoints
and not other things. If seems too targeted and specific. *Maybe*,
just maybe, the impl of the storage of the lists of endpoints is
implemented such that the endpoint objects wouldn't survive garbage
collection under some conditions. That would be a pretty esoteric
problem though.<br>
</body>
</html>