OpenSAML user discussion

[Jim Cox <>]

What jumped out at me was the explicit cast to a BasicSAMLMapEntry in
the get() of BasicSAMLArtifactMap.  This makes the use of the
interface as a contract to the StorageService somewhat pointless, if
not just wrong.

I was leaning towards a solution that was pretty much your option #1.
But your example convinced me that #2 would be cleaner.  Thanks for
the input.

-Jim




On Mon, Mar 29, 2010 at 7:35 PM, Brent Putman 
<>
 wrote:
>
>
> On 3/29/10 11:46 AM, Jim Cox wrote:
> >
> > The problem is that the BasicSAMLArtifactMapEntry stores the SAML
> > Message as a String in the serializedMessage field.  There is no getter
> > for this field in the interface.  I could cast it to a
> > BasicSAMLArtifactMapEntry, but that getter is package private. Without a
> > handle to this field, I don't see a way of re-constructing the entry.
>
>
>
> Hmm, yeah, these impls classes seem a little screwy to me.  The Basic-
> map and entry impls are tighly coupled, essentially around the fact that
> the map takes care of the serialization and deserialization of the
> SAMLObject to the entry.  This is made worse by the fact that the map
> doesn't store the original SAMLObject on the entry on the put()
> operation, just the serialized form.   That fact coupled with the
> package protected access you noted on the String getSeralizedMessage()
> (sic) method mean that pretty much, the StorageService that is passed in
> is assumed to be something that can store the entry as an object
> directly (e.g. in-memory Map), or else take advantage of the fact that
> it is Serializable (via AbstractExpiringObject) and store and recover it
> via Java serialization, none of which is documented.   To me, these
> aren't the obvious "basic" impls, they're much more specialized that that.
>
> I don't know if the failure to set the SAMLObject on the put() method,
> and the package protected access specification, were accidental or
> deliberate.  If accidental, then we need to fix.  If deliberate, then we
> probably at least need to add alternative "basic" impls of these 2
> interfaces that give the storage service access to all the data it needs
> to store and reconstitute the entry object as it likes.  I also think
> the serialization stuff in the current impls might best be in the entry,
> rather than in the map, since the entry is the thing that's
> Serializable. IMHO the separation-of-concerns is off here.
>
> For now, I think you have 2 options:
>
> 1) Use these classes as-is and in your StorageService impl, store and
> retrieve from the database using Java serialization (maybe store in the
> db as either a blob or the base64-encoded representation thereof).
>
> 2) Just write your own impls of the those 2 interfaces that don't assume
> the above approach.  There's essentially not much to them. More "basic"
> examples that strip out all the serialization stuff are attached.  That
> then assumes that your DB storage service would store the entry data
> using a relational approach over the various fields in the entry.
>
> HTH,
> Brent