<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 10/21/15 11:13 AM, Robert Eastman -
US wrote:<br>
</div>
<blockquote cite="mid:1445440424105.94868@caci.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<style type="text/css" style="display:none"><!--P{margin-top:0;margin-bottom:0;} --></style>
<p><br>
</p>
<p>I searched but didn't find any info on how the Shibboleth
SP/IdP session ID is generated.</p>
</blockquote>
<br>
I don't recall anyone ever asking. I'm sure we've always treated it
(at least for the IdP) as an internal implementation detail, so we
by definition wouldn't document it, because we're free to change
it. It's not API.<br>
<br>
<br>
<blockquote cite="mid:1445440424105.94868@caci.com" type="cite">
<p><br>
</p>
<p>What type of algorithm generates the session ids? I have a
security check that needs to confirm the random number generator
algorithm is FIPS 140-2 compliant.<br>
</p>
</blockquote>
<br>
For the IdP, see class
edu.internet2.middleware.shibboleth.idp.session.impl.SessionManagerImpl.<br>
<br>
It just uses Java's SecureRandom. Basically like this:<br>
<br>
<br>
<tt>// Instantiated once per instance of SessionManagerImpl</tt><tt><br>
</tt><tt>private final SecureRandom prng = new SecureRandom();</tt><tt><br>
</tt><tt><br>
</tt><tt><br>
</tt><tt>// on each createSession()</tt><tt><br>
</tt><tt>byte[] sid = new byte[sessionIDSize];</tt><tt><br>
</tt><tt>prng.nextBytes(sid);</tt><tt><br>
</tt><tt>String sessionID = Hex.encode(sid);</tt><br>
<br>
<br>
According to the Javadocs, that style of getting a SecureRandom
works like this:<br>
<br>
<tt> * <p> This constructor traverses the list of
registered security Providers,</tt><tt><br>
</tt><tt> * starting with the most preferred Provider.</tt><tt><br>
</tt><tt> * A new SecureRandom object encapsulating the</tt><tt><br>
</tt><tt> * SecureRandomSpi implementation from the first</tt><tt><br>
</tt><tt> * Provider that supports a SecureRandom (RNG)
algorithm is returned.</tt><tt><br>
</tt><tt> * If none of the Providers support a RNG algorithm,</tt><tt><br>
</tt><tt> * then an implementation-specific default is returned.</tt><tt><br>
</tt><tt> *</tt><br>
<br>
<br>
So that actual impl used at runtime is going to depend on the
presence and ordering of the Java security providers configured in
java.security that expose impls of the SecureRandom service.<br>
<br>
I personally don't know anything about FIPS 140-2 compliance wrt the
standard/common providers.<br>
</body>
</html>