Prev
Next
Forums Infor / Lawson Platforms S3 Systems Administration

SSO with multiple requester codes

 2 Replies
 0 Subscribed to this topic
 27 Subscribed to this forum
Sort:
Author
Messages
Mike Schlenk
Veteran Member
Posts: 71
Veteran Member
10/21/2009 1:30 PM

    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.

    Attachments
    Jimmy Chiu
    Veteran Member
    Posts: 641
    Veteran Member
    11/12/2009 7:55 PM
      I switch my requester code all the time (for troubelshooting user issues) and I can tell you this method will not work. It will take time for LDAP to sync and reflect the changes in lawson, sometimes up to 10 minutes or so unless you bounce the server.

      mark.cook
      Veteran Member
      Posts: 444
      Veteran Member
      11/13/2009 12:31 PM
        We looked at how we could manage the users for multi-company as well. We are LDAP bound, migrated from LAUA to LS over a year ago, use process flow for approvals and what we found was there is no easy way to handle the maintenance of mutliple requestors.

        What we did is have one Requestor ID and we opened up the company field on RSS. This allowed the RSS users to default to their main company for ordering but allows access to order for the other company. The only issue we have to monitor, which should be caught in the approval process is that the second company we could not tie down to particular accounting units in that company.

        Overall, we are not having too many issues with this process and it keeps us out of the business of maintaining the requestor id's.

        Below is the options we looked at and we chose option 2.

        Disclaimer: Since some options deviate from the way RSS is designed to work, there is no guarantee that either will work and should therefore be tested and validated.

        Option 1:
        -User has a single requester ID
        -rssconfig is not modified. Company field is display only and will display the company value assigned to the requester on RQ04. NOTE: User could potentially use RQ10 to order for any company (dependent upon security).
        -User uses RSS to order for company 1000. RSS will default to company 1000 and will not allow a user to select any other company.
        -User uses RQ10 to order for company 6000. User will be able select a company on RQ10 (dependent upon security)

        Option 2:
        -User has a single requester ID
        -Modify rssconfig to allow company field to be a select. Dependent upon security, User will choose the company for requisitions.
        -User does not need to go to RQ10 since they can choose the company to request.


        Setting Description
        "allow_company_select"
        value="false"
        Indicate whether users can change the company on a requisition before the requisition is assigned a number.
        Changing the above to TRUE will allow company select.

        Option 3
        -User has multiple requester IDs, each tied to a different company. The second requester ID is stored in a custom attribute
        -rssconfig is not modified. Company field is display only and will display the company value assigned to the requester on RQ04. NOTE: User could potentially use RQ10 to order for any company (dependent upon security).
        -This URL executes RSS with a specific requester (Overrides the default):
        http://{Server}/rss/html/index.htm?newreq=true&requester={RQ04 REQUESTER}
        The link doesn't let them pick a Requester within RSS or Portal. The link provides a means of building Bookmarks for specific requesters and in that sense allows them to select a Requester.

        Example:
        By default you are Requester (Default0000) but you need to be able to order for several companies which require different default values on RQ04. You would build a bookmark with child links for each requester I need (Requester1000, Requester2000, etc) and then assign that bookmark to the individual. Instead of clicking "Shopping" they would click the bookmark of their choice when they want to order for someone other then their default. The link will start RSS and use the requester in the link overriding their default.

        Note: Have notice that in some cases the system holds onto the old requester when entering RSS through "Shopping" as a rule they should always click the "New" button which is a fix for almost all issues in RSS but in this case it resets based on the values used when starting RSS.

        This method requires some setup in Portal Bookmarks and of course the additional RQ04 Requesters and as rule is an exception and not rule. If you have large numbers of users needing this functionality, it could result in a lot of work.
        We have been using this method for awhile and it has worked out great. Requisitions are created within the correct company and Purchase Orders/Pick Tickets are created under the correct company. In addition the User only has 1 Login ID.


        NOTES
        SS uses the Requester ID stored in the requisition service to validate access into RSS.
        That requester ID is recorded on every requisition.

        The company number on the RQ04 record is a DEFAULT not a limitation for requisitions.
        Security limitation is set to allow or not allow access to the other companies, Not the setup in requisitions.
        If you use 1 ID on RQ10, you can change the company and location that you want to order for on every requisition. Same is true in RSS IF the company field is a select, not a display only.






        In RQ04, you have the option of limiting access within the default company to specific accounting Units. When ordering for multiple companies whose GL is different, this can pose an unexpected limitation. However, you can still apply accounting unit limitations using security instead of using the RQ04 record.
        If you remove the accounting units from the Requester ID (RQ04), you might want to look at adding accounting unit limitation on the user record.
        That way you can still control the accounting unit access for all companies