[midPoint] Midpoint features

[Radovan Semancik]

Hi Lucie,

On 01/17/2014 03:44 PM, Lucie Rút Bittnerová wrote:
> 1) Can a user request for some role? There is a child element 
> "requestable" in xml schema for element role but is it supported?

User requests a role simply by assigning the role to himself. If no 
approvals are configured then the role gets assigned immediately. If 
there are approvals then the approvals are processed first and the the 
role is either assigned or the operation is cancelled.

However there are two things to consider in midPoint 2.2:
* Authorization scheme of midPoint 2.2 is very rough. Simply speaking 
you can only give user a privilege to assign all roles or no roles at 
all (in fact the authorization is even broader).
* There is no special part of GUI that can be used for user to assign a 
role just to himself.

Both of these should be greatly improved in 2.3. But if you want a 
solution for midPoint 2.2 then the best strategy is to create a simple 
end-user interface that will process role requests from the users. Such 
interface can then use midPoint webservice to initiate role request in 
midPoint. The custom end-user interface can also enforce any kind of 
authorization mechanism. Creating such simple GUI should be very easy 
for any reasonably experience web developer. There is also a Java client 
code with samples that can be used by your custom GUI code to simplify 
the development of such interface in Java. Other platforms can use the 
web service using their own tools (we have WSDL/XSD definition). E.g. we 
have information that .NET web service clients works reasonably well.

There is actually very strong reason behind this: The end-user 
interfaces usually take many forms in IDM deployments: Java portlet, 
proprietary plugin into enterprise portal, custom portlet (e.g. in 
liferay), integrated with "primary" access mamagement system (such as 
AD) and so on. Therefore we haven't invested much effort in midPoint's 
end-user interface until midPoint user's  specifically request how the 
end user interface should look like and what exactly it should do. We 
have some requests already and these will be reflected in midPoint 2.3. 
If you have any specifications or idea how the midPoint end user 
interface should look like in the future we will be very grateful if you 
can share them. This kind of feedback will help a lot to guide future 
midPoint development.

The "requestable" property of roles is meant to allow GUI to list only 
the roles that are normally requestable. This property is currently not 
used by main midPoint code and it is there especially to support custom 
end-user GUIs: the roles can be searched using midPoint web service and 
therefore the custom GUI can display a list of relevant roles.

> 2) I need finer granularity for authorization. For example I need to 
> allow a user to read his attributes (but  not to modify them) or to 
> modify selected attributes. Are there any plans to support this feature?

Yes, there are. This is part of our "delegated authorization" feature 
and it will be supported in midPoint 2.3.

> 3) Is it possible to be allowed to add/remove roles of users but 
> without possibility to change user attributes?

Not in midPoint 2.2. But this is planned for midPoint 2.3.

> 4) Is there any support for time limited roles?

There is limited support for something that we call "time constraints" 
in mappings and also limited support for "validity intervals". MidPoint 
2.2 officially supports that only for users, not for roles. However the 
code that is processing the time-related properties is very generic and 
it may either (unintentionaly) work in 2.2 or may be very easy to fix in 
2.3.

It looks like waiting for midPoint 2.3 is your best option here. It is 
currently under development and the release is planned for late 
spring/early summer. However the development code is in a pretty good 
shape. If you are interested in these features and you have some time it 
could help a lot if you could help us with specifications and testing. 
What we want exactly:

1) Specify your use cases.
2) Communicate with developers while the features are being developed.
3) Test the features (in development version, before release).
4) Repeat steps 2 and 3

This approach will greatly improve the chances that the features that 
you want will be part of the next release and that they will actually 
work well for you.

As you are not the first one who asks for a new feature I have found a 
time to write down the guide:
https://wiki.evolveum.com/display/midPoint/Feature+Request

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com