FOKUS: More flexible wildcard and redundancy mechanism in LOGIN objects

Idea created by Carsten_Schmitz on Apr 13, 2018
    Under review
    In UC4, agents determine the desired user account by looking for matching accounts in a LOGIN object.

    LOGIN objects have extremely limited wildcard functionality: one can use exactly one wildcard, namely the asterisk, which can not be part of an expression but only stand on it's own. In other words, LOGIN objects can only have one wildcard entry: *

    The cascade in UC4 then works like this:

    1. is there a specific entry for the agent? If so, use it.
    2. is there a wildcard entry? If so, try to use that.

    I propose two adjustments to this, to make LOGIN objects much more flexible:

    a) for the agent names, allow expressions with wildcards as a part of the expression. So one can have for example these LOGIN Object entries:

      a1) *
      a2) UK*
      a3) UKHQ

    This should be resolved by the most specific entry first. In this case, an agent named "UKHQ" would use the third entry, an agent named "UKOFFICE" would use the second entry, and an agent named "USOFFICE" and thus not matching the second OR third entry would use the overarching wildcard from the first entry.

    b) ADDITIONALLY, I propose the introduction of a new column in LOGIN objects to designate a hierarchical order (from here on called "level"), very much like the ordering of permissions in the permission system. Thus one could have a LOGIN object with entries such as:

      b1) *   level 0, accountname "flamingo"
      b2) *   level 1, accountname "pelican"

    In practice, UC4 shall process the levels by their given order, ascending. So for an agent matching the wildcard, it shall first try the account "flamingo" and if the login fails, it shall try the account "pelican".

    The former should be straightforward to implement, as any greedy-type regex engine should be able to resolve the most precise expression for a given agent name. It could, in my assessment, be implemented without breaking backward compatibility.
    The later would require signficantly more implementation effort (as it requires changes not just to LOGIN objects, but also to the way jobs are started). It can be implemented fully backwards compatible in my assessment simply by making "level 0" the default for all existing LOGIN object entries.

    If supporting this proposal, please indicate in the comments how important part "a" and part "b" is to you, respectively.