Commenti di Scott Cantor sulle guide IDEM - errori e miglioramenti
Opened this issue · 1 comments
daserzw commented
Errori e miglioramenti notati da Scott Cantor. Processiamoli uno alla volta aprendo una issue per ognuno.
Cantor.2@osu.edu Scott Cantor added a comment - 5 days ago
I'll try and cover all the problems here as best I can. I'm not just closing out the bug because I still think it's a bug (though not ours), but this is really more of a "how not to configure the IdP" set of issues.
1. You're using a database for a bunch of things you absolute do NOT want to use one for and don't need to be. I doubt you're even using SAML artifact support, are you? if you don't have a back channel, you can't be. So that doesn't matter much. But you most definitely do NOT want to use a database for sessions. You should use client side sessions unless you can provide a strong argument as to why you shouldn't. We provide the software defaulting to that for a reason.
2. You have the computed ID strategy property there uncommented, so your identifiers must be, for the most, all coming from the original salted hash approach and just being stored in the database that way. You can look at the stored ID table and check, and if they're all long and base64 or base32-encoded, and not just simple UUIDs, then you don't need a database for them at all. Dump the stored ID approach and leave it configured to produce them with the computed approach alone. Major problem solved there.
3. You're sharing the same DataSource bean across two different subsystems when you could easily separate them into two, and have the StoredID support (which you don't need most likely, see #2) separate from the StorageService support. That solves the "nothing works when consent fails" problem. Isolation is good.
4. I still have to assume the problem here is your driver and/or the settings. We don't really provide support for that layer but offhand I don't see anything obvious. Without much more logging, there's really nothing I can say about the driver (other than make sure it's the absolute newest one you can get).
I do think you created the storage service database with the wrong schema, perhaps. The context and key columns have to be be case sensitively handling the primary key constraint, which should make the new records non-conflicting with the originals that had the mixed case. If that's not possible in the database you're using, it can't be used, but I assume it just wasn't created correctly. It could also be a Hibernate limitation, I don't know anything about it, but I'll ask the author. It seems like it must be finding the old records on a case-insensitive search, so that might be the root of it.
After the fact, getting the records updated to fix the mixed case would seem like the obvious fix to me. You can't make it work any other way if it's going to keep failing to create those new records, even if the connections didn't become unstable when it failed.