Here's a fun one:
We're looking to implement Lawson single-sign-on. To us, this means we are moving from LAUA to LSF security and consolidating logins. Eventually, we want to bind to and external LDAP source, but that's down the road.
We're starting with ESS, MSS and RSS logins (leaving app users for last). Currently everyone has a base login that matches their network login. If they're a manager they also have networkID-mss. If they're a requester they have networkID-rss. If they request for multiple companies or need multiple requester codes in any way, they have multiple IDs (networkID1-rss, networkID2-rss, etc.). We have a web-based, pflow driven password reset process to keep all of the passwords the same. Obviously there are problems when consolidating logins since a user can only be attached to one reqeuster code.
I was brainstorming with the admin and we have a cool idea based on tricks we've used in the past. NOTE: We don't ever want to update the Tivoli LDAP with anything but Security admin or pflow.
The idea is as follows:
- Create multiple identities in the security admin to hold the multiple requester codes.
- Create a new php page (we've enabled this on the server for custom development) that queries LDAP to see if they have multiple requester codes.
- If they don't forward as normal to RSS
- If they do, present the list to select from, then use PHP to write the selection to a work unit, use pflow to change the main requester identity to the one selected, then forward to RSS. All the while, the PHP page initiating the work unit must pause to get this done.
I think it's a pretty slick idea that poses little risk outside of it's inherent complexity. We'd have to build in defaults and notifications is something doesn't work right. The pausing would have to be pretty fancy to know when the pflow is complete (should be able to do this with a file) Plus, I'm concerned about potential delay/sync issues with the LDAP.
Ideally we're opening up or redesigning requester codes so none of this is neccesary, but we're still faced with requesters for multiple companies.
The other thing we thought of is that the ReqRejectEmail flow needs to be altered not to just find the user(s) with the assigned requester code but search the potential multiple IDs as well.
That's our idea. We're obviously committed to staying away from multiple logins (at least for portal). We've done fancy stuff like this in the past for password resets, ESS and things like that so we're confident. Any thoughts or alternate solutions are appreciated.