Add a batch job (or a pre-packaged external utility) to clean up unused auto-enrolled user entries

[aliaksander-samuseu]

Currently we don't seem to have a straightforward way to manage users auto-enrolled by custom scripts. In big deployments it may become a significant problem. If an authentication method relying on external source of identity is removed from configuration, users that have been enrolled by it so far must be removed trough some other means, like using direct writes to persistence layer, or via SCIM. User entries that are no longer used will accumulate in database and will require each organization to write a custom code, a scheduled job that will purge stale entries.

On the other hand, as this kind of user entries can be re-enrolled as needed - i.e. if an user will decide to log in after a long period of inactivity - it may not be a big problem if their Gluu user entry is no more - as it can enrol them again. Some attributes on the new entry won't be the same (like, "inum"), but main set of attributes released to SPs and RPs will be (and should be enough) - as it's passed from external IDP each time.

Suggestion:
As user entries may have oxLastLogonTime attribute attached, a new feature could be added that, if enabled, could on regular basis purge external user entries that haven't been used for specified amount of time (similar to how tokens are already purged now).

It must do exception for users added to "Managers" group, though, as membership is defined by DN which contain "inum" of the current user entry of an admin user.

[devrimyatar]

@yurem Shall I write a script for this?

[yurem]

Yes, I think external script will be good for this. Moreover we can allow admin to run it with additional (non default settings) to do clean up.

For me clean u should do user removal in 2 steps:

1. Change user status to inactive and add attribute to specify where it change user state
2. Do clean up if user inactive during specified time

oxLastLogonTime usage can be turn off in oxAuth config to get maximum performance.

[jgomer2001]

Sounds good. Let me try to formalize it a bit for @mbaser :

Description:
Removes user entries that have been auto-enrolled by means of passport. This script allows to remove or deactivate entries corresponding to users that have not logged-in after a specified date.

Notes:

• No entry belonging to an administrative group will be considered for this process.
• Entries linked to an external provider post-account creation (eg. by means of Casa account linking plugin will be considered).

Params:

• remove: If removal of accounts should take place. When ommited, the accounts will be only deactivated (by setting status database attribute to inactive)

• provider-only: Account only user entries that have been enrolled through the designated provider. Examples: "github", "my-OP-1", "Okta-1234". The value must match the identifier assigned to the identity provider (in oxTrust form Passport > Providers). When ommited, removal/deactivation applies for all providers found in oxExternalUid database attribute.

• last-logon: Removal/deactivation will take place upon entries whose last logon time is earlier than the provided value. Example: "2008-11-30".

Impl. details:

• oxLastLogonTime attribute contains the last time a user has logged in.

• Entries applicable are those having oxExternalUid matching passport-(saml|social):(\w+):(\w+)

• $1 contains the provider identifier (in case of provider-only usage)

• I think we should dump to a log the removed entries. When they are just deactivated, I think dumping the DNs suffices. Yura also suggested filling an additional attribute, for instance statusChanged with the change date (ie. when the tool was run).

[jgomer2001]

I made a mistake wrt this:

Entries applicable are those having oxExternalUid matching passport-(saml|social):(\w+):(\w+)

The following lists some examples of oxExternalUid for more clarity:

oxExternalUid	provider_id
passport-github:mbaser	github
passport-something:jose	something
passport-saml:okta:mike	okta
passport-saml:ADFS:alex	ADFS
passport-gluu-server:chris	gluu-server

Also account that oxExternalUid is not exclusively tied to password. It can have other kind of values, eg: cert:ey...blah...., htop:random_string_here;number.

That means we have to check the value starts with passport- and that there is non-empty string after the last colon (:)