The checklist provided here is intended to help you with the configuration and functional testing of IUM.



In the first step, two new groups (IUM_user_software and IUM_access_software) are created under "Administration" - "User management" - "Groups" (alternatively, other names can also be used).
If Jira Service Management is installed, two new groups are also needed here  (IUM_user_service and IUM_access_service)(alternatively, other names can also be used).

  • Sense of the new groups
    • Casual users will later be moved to the IUM_user_... group (power users remain in their original group).
    • If occasional users need a licence, IUM temporarily copies the corresponding user into the IUM_access_... group and the user is assigned a licence.



Under "Administration" - "Application" - "Application Access", access for the IUM_access_.. group is now added for Jira Software and/or Jira Service Management.


User Directories

If the "Jira Internal Directory" is not used, the LDAP permissions ("Administration" - "User management" - "User Directories" - "Edit") must be changed to "Read Only, with Local Groups".



The actual configuration is then carried out under "Administration" - "Manage apps" - "IUM Configuration".

  • Group Settings
    • IUM_access_.. is selected under "IUM Application Access Group" and IUM_user_.. under "IUM User Group".
      (or the corresponding self-assigned names) Jira Service Management is only displayed if it is installed.
    • The number of licences to be managed by IUM is entered under "Queue Size".
      (e.g. if there is a 500 licence tier and 100 power users, then 400 licences are available for IUM to share)
      • Queue Size + permanent User <= Licence tier!
    • Under "Duration in minutes" the minimum inactivity time in minutes is specified before the licence is released again.

                     


  • Design
    • Logo:
      A URL to the company logo can be stored here for display during the waiting time.

    • Queue message:
      Here you can define your own message for the queue display.

                           


  • Rest
    • The entry /rest/api is already stored internally by default and do not need to be added to the rest-api configuration field. In case you add it, it will be hidden
    • additional api's can be entered here (e.g. /rest/scriptrunner)

                   


  • Logging
    • Switching the internal log on and off
    • Toggle debug mode on and off for the log files

                    


  • There are two options for user management (adding users to the IUM user group).
    The easiest way is via Automatic User Sync
    • Automatic User Sync Job

      • A job can be set up here that synchronizes the users from the selected origin groups into the IUM user group. The users remain unaffected in the original groups.
        Users with a fixed license from another group and deactivated users will not be synced.

      • The User Sync can only be executed for Jira Software or Jira Servcice Management or for both.
        (Before changing the group settings, first switch off the current job.)

        • Original Group
          The original groups can be selected here.

        • IUM User Group
          The IUM user group specified in the group settings is automatically adopted here.

      • Execution intervall
        Execution times 1h, 2h, 3h up to 24h


      • Start time
        The start time of the automatic removal can be set here (the time refers to the server time)


      • Enable/Disable job

        • next running time (the time refers to the server time)

        • Server Time (Current Server Time)

        • After restarting the instance, the job must be activated again
        • Last execution date

      • Manual job
        Execute the User Sync process once.

    • The second option is to move the user manually

      User Management
      • This is where the actual moving of users into the group managed by IUM takes place.
      • Under "From Group", the group in which the current users are located is selected.
      • Under "To Group" the IUM_user_.. group is selected.
      • After clicking on "List", a list of users from this group is displayed.
        • The users displayed are sorted in descending order according to their last activity.
          (thus, the occasional users can be sorted out little by little)
        • The number of users displayed can be set under "Number of Users".

                   


      • Now the users that are administered by IUM are selected via the selection field.
        (no power users should be selected here, but the occasional users should be gradually sorted out)
      • With the "Move" button, the selected users are now moved.
      • The "Copy" button is used if the IUM_user_.. group is made up of individual permission groups and does not have its own application access.

                    


      • Moving users can not be undone!

                   


      • After confirming the process, you can see in Jira's user management that the selected users have been moved to the IUM_user_.. group.
        (the unselected power users (User5, User6, User7 and User9) remain in their old group)



      • please check: It is important to ensure that there are no users with a permanent license (e.g. from another group) in the IUM groups (user/access).

                   

  • Automatic removal

    • Activates the automatic removal of users from the IUM access groups if the last activity is greater than the duration entered in the group settings.
       


    • Inactivity time in minutes

      Here you can define the inactivity time a user must be inactive to be removed from the access group.

    • Execution intervall
      Execution times 1h, 2h, 3h up to 24h


    • Start time
      The start time of the automatic removal can be set here (the time refers to the server time)


    • Enable/Disable job

      • next running time (the time refers to the server time)

      • Server Time (Current Server Time)

      • After restarting the instance, the job must be activated again

    • Manual job
      Click run job to purge the IUM access groups once (if the last activity is greater than the duration entered in the group settings, the user is removed from the access group).

  •  SAML
    • IUM supports single sign-on services such as ADFS, Azure, Google or Okta. (How to setup)

                   


Control

  • Two users have now logged in. (User1,User8)

           

  • You can see in the user administration of Jira that the two users have been copied into the IUM_access_.. group and thus also have access
    to Jira software and/or Jira service management. (depending on what was previously defined under "Application Access")
  • After logging off, the user is automatically removed from the IUM_access_.. group and the licence used is free again.
  • If a user simply closes the browser (without logging out), he or she remains in the IUM_access_.. group until the licence occupied by him or her is needed.
    Only at this point will they be removed from the IUM_access_.. group.

         


  • Since in this example only 2 licences were made available for administration by IUM for "Queue Size", the following display appears for the third user
    third user the following display appears.


    • After the waiting time has expired, the user with the longest inactivity time is moved to the IUM_user_.. group, his used licence is released again and the waiting user is logged in.
    • If a logged-in user is inactive for longer than the time specified under "Duration in minutes", this user is moved directly to the 
      group IUM_user_.. and his used licence is directly passed on to the new user.
      (The queue would not be displayed in this case)