UI Enhancements

Last modified 08 Sep 2022 11:24 +02:00
This page is a stub, it is a work in progress.

This document contains notes for designing self-service user interface. Mainly for requirements of Role engineering and maintenance and Role request processes.

Principles and requirements

Easiest terminology possible

Directed for people with near zero knowledge about Identity and access management.

Beware of: Entitlement, Inducement, Assignment, *ment, Archetype, Relation, Delta, Resource and any other terminology created specifically for Midpoint.

We should start using term "access" for role assignment. It is easily understandable for end-user. The role XYZ:User gives you access to the application XYZ. We should start using "Request access" instead of "Request role".

Fast and easy

People just want to easily and quickly find what they need to do, do it and close IDM. This must be delivered and supported by the design.

Information must be delivered in business form

User should see the data in business form E.g. user history - it should have list what happened to user - user does not need to open each item for searching what has happened, but having view and in each line having datetime of the change and (if possible) field or few fields that was changed and (if possible) it’s value. Of course not for each attribute for user creation.

Midpoint has quite sparse screens - more info on one screen is necessary.

Opening multiple objects in tabs

It is quite common that user is comparing 2 objects. (E.g. manager sets access for his team according one team member. He opens the team member and on the other window, he configures other person.

This is so common operation pattern for end users (copying the data from one object to another), that opening the object in new tab is a must.

Delegations

TODO: how exactly to handle this. - probably existing way is enough. Need to review.

Self-service components

Self-service section should contain following sections:

  • My profile

  • My passwords

  • My access

  • My roles

  • My approvals

  • My requests

  • My teams

  • My preferences

Self-service details

My profile

Contains user’s attributes. User can modify them based on his/her privileges.

  • Zastupitelnost (delegations) → kazdy user si moze nastavit zastupcu, kto ho bude zastupovat v schvalovani v IDM.

My passwords

This is password self-service. People do-not understand word credentials. Password is better.

My access

Main self-service screen for requesting/removing and modification of user’s access.

Here, the user can see w - rozdelenie: ○ business level ○ applications § a pod nimi aj ake roly ich prideluju - moje opravnenia - tu mozem poziadat o novu rolu, ○ mozem aj poziadat o jej odobranie ○ mozem menit atributy jej priradenia - tu by som mal vidiet aj "my requests" - vsetky requesty, ktore som urobil, ich stav (a v detaile aj ich priebeh). - organizations ○ do ktorych organizacnych jednotiek patrim § mozu byt rozne organizacne struktury - tak pre kazdu strukturu nejaky popis. - application access

My requests

Users requests - active and historical. Here can user see what is the state of his requests.

These requests should be in view with correct information.

Following chapters:

  • My requests (for me or for somebody else)

  • Request for me

  • maybe also Request for my team or My team requests

History - in separation to my requests or requests for me

  • requesty, ktore som mal - cize co vsetko som robil a bolo nakoniec schvalovane.

  • my requests - tu su requesty, ktore som urobil ja

  • requests for me - tu su requesty, ktore urobil niekto pre mna

  • kvoli performancu zobrazovat najprv requesty za posledne obdobie (mesiac/3 mesiace) a vsetky az po nejakom rozkliknuti.

Mozno toto by nemuselo byt, ale tie requesty by mohli byt dostupne v historii usera …​ Neviem presne.

My approvals

List of approval tasks. By default - active tasks, but also history should be available (after some click).

The data should be visible in a table - for fast view and fast approval processing. This is necessary to vyvazit generation of many approvals because each role assignment has

  • Active (tu by malo byt zobrazene, co kto pozaduje v tabulke, aby clovek nemusel otvarat, ak nepotrebuje) ○ Access request: § Date Operation Who What Why .additional info. <Approve><Reject> ○ Role update § podobna tabulka ako vyssie. ○ Other: § sem nejake ine approvaly.

  • History (last 30 days / older) ○ Tu mozem pozerat vsetky approvaly. Viem ich otvorit. Su ale iba read only. § Pri otvoreni sa zobrazi celkovy request aj s worflowom a business informaciami.

My teams

This is space for delegated administration, just this is standard user, not IDM administrator. Additionally, team manager may see his subordinate attributes and access of his subordinates.

User with to for people having specific role (e.g. team-access-manager) can modify attributes for the user and his assignments (access).

Optional - advanced: The standard user may see also his team members

Notes:

  • zobrazenie clenov timu - podla roznych organizacnych struktur ○ zobrazit iba ak vediem team, pripadne som v nejakej pozicii administratora teamu

  • moznost vidiet pre toho clena timu a vediet ho editovat ○ vediet mu editovat atributy (note: ziadne schvalovanie tu nebezi) ○ vediet pri roliach: § pridelovat § odoberat § modifikovat atributy ich priradenia ○ <RESET hesla ???> → Toto by bolo fajn, ale neviem isto, ci to je vhodne

  • moznost pridelit cloveka v ramci organizacnej struktury ? ○ tuto by bola moznost pridelit si hocikoho do teamu a zmenit ho. ○ neviem, ci je to dobre. Asi to vytvaranie

  • bude bezny user moct vidiet aj ludi zo svojho timu ? - aby sa vedel pozriet, ake opravnenia potrebuje. ○ tu by ale boli veci iba read-only

My preferences
  • tuto mozno ako by mal mat user zobrazovne veci. Zlepsenie citatelnosti a zrozumitelnosti udajov v GUI.

  • Language: - different people may need different language versions. This may be harder for implementation.

  • Date & time format - Important! Date & time format must be correct - at least the same for whole installation.

  • 12/24 hour format

  • Thousands separator

  • Decimal separator

Was this page helpful?
YES NO
Thanks for your feedback