Documentation of Attribute Types and on Demand attribute value determination

[thbuett]

Hello experts,

is there any documentation about the attribute types in the Storage tab and what effect they have. What does it mean, when a attribute is from type

• General attribute
• Member-of attribute
• Approval attribute
• System attribute
• Referral attribute

What are useful combinations of Attribute Type, Data Type and Presentation?

Currently we are trying to create an attribute that determines the value in the UI on demand using a SQL expression without writing them hard to the database.

We don't care about the UI, because we primarily use the REST API. I have hopes that this can be achieved via skillful choice of attribute properties.

The extension framework would be a solution, which unfortunately is a bit more maintenance intensive.

[lambert-giese]

This should be possible using a plain "General Attribute" of type "Text", a presentation type of "Single Select" and your SQL query in "Allowed Values". The screenshots below show a complete example plus runtime result in Postman. Don't be confused about the runtime "VALUE_TEXT" I get in Postman. It's because I have an Oracle-specific query in Allowed Values which generates JSON, so my "Allowed Values" at runtime are JSON values. This part probably doesn't match your use case. Your query could return character data, of course. It need not be JSON.

[thbuett]

Hello Lambert,

thanks for your detailed explanations. I had the idea with the allowed values as well, would just require all consumers of our API to adjust the read methods, since when reading a person via

/idmrestapi/v2/service/ET_MX_PERSON(ID, TASK_GUID)/<attribute>

you can't get the values, because they are not in the DB anymore. I was thinking more of some kind of virtual values.

Besides the REST API, of course, all passes are affected in which I want to read the value of this, let's call it, virtual attribute, to provision it into other systems or make process decisions. Therefore the way about allowed values is applicable but not trivial.

As said I had the hope that about a skilful attribute configuration so a kind of virtual attribute can be generated, which simulates the result of the allowed values as an actual attribute value.

Greetings,

Thomas

[lambert-giese]

OK, I didn't get this point initially. I think the only way to achive this end will be extension framework, though. A simplified way of implementing the framework - which doesn't require any Java implemention on your own and instead allows implementing all your custom logic for the extension framework in JavaScript is Rhidmo (you'll find it on GitHub). Maybe you want to have a look.

Keep in mind though, that even the extension framework -with or without Rhidmo- cannot provide attributes whose value is never persisted, but calculated dynamically whenever there's a read access to their value - e.g. during a connector's pass execution on provisioning. This isn't supported in SAP Identity Management at all. Personally, I think many may consider such a feature more of a bug because it would provide a loophole to bypass one of the product's strongest assertions: the ability to audit any changes applied in the past to any of a user's attributes.

[thbuett]

Ok,

just when you say the strength is auditing, then I totally agree with you, that would no longer be fully given in that case. But I wasn't concerned about writing the attribute, more about having a lookup to save the REST API clients from role tree traversal.

Possibly, though, I should rethink our concept of what this Dynamic Attribute is supposed to represent.

The idea was, roles map user categories. An attribute on the user aggregates these mapped user categories as a "lookup attribute", so I don't always have to evaluate all roles to get the full set of user categories, but simply read the value of the attribute and thus with one query have the full, currently valid list of user categories. Which ones he belonged to and when is obvious from the role assignment and their audits.

But you give me an idea. In principle, I'm more interested in storing the SQL query somewhere central, so that I can access it from anywhere. And I wanted to map that via an attribute, but maybe I need to go deeper and map it via a stored procedure or function or view and then just use that everywhere.

For one thing in ExtFwk, for the Allowed Values and the Passes in the form of a script.

I'll go with all of that. Thanks to you for the constructive exchange and your help.