It seems that the event handler does not have a condition on user resolver and only user realm.
I would like to request a feature to add condition on user resolver for event handler.
Moreover, regards to the early issue with token ownership issue with moving user between resolvers (Resolver and User token relation), it may also be helpful if you can also come up with similar solution for event handler condition too, so that enterprise can have option to reduce the use of resolvers for fine tuning policy/handler behaviors.
Currently this necessity did not pop up in any of our consulting workshops with enterprise customers. So I am wondering, what (and why) you wanted achieve in the first place.
I think often customers think to miss a certain feature, but after some discussion and understanding there are usually other ways to address the needs.
Anyhow, adding the resolver as condiiton to the event handler would be fairly simple.
On the other hand, the adding any user attributes to conditions would be a more challenging task.
The use case is for example, we need to send out email notification for the same condition, but with different email template to users depends on their resolvers.
For example, in the same realm, we have different resolvers to fine tune the user enrollment policy of what token they allow to enroll. So, the email should also reflect the guidance differently per those resolvers.
Moreover, since we still have the problem of moving user between resolvers will lose the user original tokens, I added a note that seems like even if we add the resolver filter in event condition, we may face the same inconveniency. So, hopefully, you can also take that into consideration when add the feature for user attribute filter for policy.
thanks a lot for sharing this use case. Makes absolute sense!
I am sure we will do these additional attributes in pI 3.x.
We are hot on 3.0 for the python 3 support and some major DB changes. I am not sure, if we can squeeze it in there.
You may track this issue:
I just discovered this issue too. I moved a user between two resolver and lost the connection between the user and their token. To work around this, I unassigned the token, and then reassigned it. I’m in the process of reworking my resolver to avoid this in the future. Is there a way to export token assignments to a cvs, or to do a view all instead of n users per page? This would be helpful to me with unassigning/reassigning.
this is not an issue but the underlying concept.
Having a token assign to a user object in a resolver will not change in version 3. And will not change soon or every.
This is why you need to think about, how your users are actually organized.
Either dump the db table token or use the API to call
http --verify no GET https://localhost/token/ authorization:$TOKEN pagesize=1000
After retrieving the authorization “$TOKEN” with the /auth endpoint.
Note that you can use the pagesize to retrieve a lot of tokens at once.
we removed this from our 3.0 milestone, since 3.0 is basically a release, where underlying concepts change.
Python 3 support => a lot of code changes (roughly all the code)
cryptographic lib changes
immense DB changes: The user assignment will be removed from the token table and stored in its own, new database table.
It is important for use to get this shipped. Lately we sat togeather and moved some features to the next release 3.1 (otherwise we would not be able to finish the 3.0)
In addition we realized, that we also need a redesign of the policies and make them more harmonic with the event handlers.
Currently the policy table contains a lot of information - some of the columns are like conditions for the policy and others are the action. Why are conditions static in the policy table? This makes it difficult for us to add a new condition like the arbitrary user attribute. Why do the action only have one column?
This makes it difficult to parse the action…
So you see, as we want to make this right we had to move this to 3.1.
Then we can add the user attributes and use them in arbitrary conditions in policies and event handlers.
The customer requirement to have different email templates for user population indeed evolved beyond the resolver concept. So if that configuration can be independent from the resolvers and be based on an independent LDAP filter it will indeed provide more flexibility. To elaborate on what Quynh mentioned the customer wants to send different notification emails (used in their case as registration emails) to enroll different types of tokens or addressing different populations of users who require “special handling”.
