Content Management and Capture

I have configured WAS V9.0.5.21 TRAD (CPE V5.6.0) with the setup of OIDC to support external idp Okta. We do not use Content Navigator, only FileNet API.

The OIDC config is setup and working but when we go to use the OpenTokenCredentials API we do not get access to FileNet. We are passing in the email address using claim 'sub'. Our test user in LDAP does have the same email. How do we map idp identity to user in LDAP? Some users will be in LDAP, some won't.

As a workaround, we added a Managed Directory Configuration in Acce (adding email domain from idp) and added the user to the Managed User Realm (default state = Provisioned) and we were able to use the OpenTokenCredentials API to get access to FileNet without issue via #authenticatedusers

I understand the Managed Directory Config approach to be applicable only to ICN where user starts as provisioned then moves to Confirmed by means of Identity Rule either Allow/Allow Self registration so while we have it working it can't be the final approach as there are hundreds of external users so we can't add them manually.

The users in the idp are/will be in the local LDAP but some may not be so we need to handle both user registry users in idp (matching somehow) and some who are not.

Has anyone achieved what we are trying to do or does anyone have any guidance on the access to the CPE portion which is where the issue lies.

We have these properties below setup in the WAS for OIDC in the interceptor. Are we missing something here to make it work?

We also understand the property named mapIdentityToRegistryUser to only be applicable to ICN use cases so haven't gone that path. We also don't have any other property in the idp other than email so our scope is set to openid email.

Any help or guidance would be most appreciaated.

How are you distinguishing users that are in your LDAP vs external users not in your LDAP that are authenticated by the same IDP?  Do all your LDAP users have the same email domain suffix, whereas your external users have different email domain suffixes?  If so, there are a few ways to handle this.

Option 1

Create two Managed User directories

• Managed User directory 1 would be for users in your ldap.  Create an Allow Self Register identity rule containing the email domain suffix for these users
• Managed User directory 2 would be for your external users.  If you have a fixed set of email domain suffixes, then you can create Allow Self Register identity rules for each email domain.  Worst case is that you create Allow Self Register identity rules for each top-level domain name (i.e. "com", "edu", "gov", etc.)

Note that since you are not using ICN, all users who self-register in this fashion will remain in the "provisional" status.  The only way to get them into the "confirmed" status is if they login via ICN.  However, users in the "provisional" status can still be authorized and assigned to the security of documents/folders/etc. in the normal fashion.  The only caveat is that users in the "provisional" status are subject to be automatically removed based on the "Unconfirmed User Cleanup Interval Days" property of the Managed User Directory configuration.  However, is you set this property to 0, then that will disable this automatic cleanup.

Option 2

Create LDAP directory and a Managed User Directory

• The LDAP directory would be for your users in the LDAP
• The Managed User Directory would be the same as described in Option 1 for external users, except also add a Block identity rule for your ldap users, so that your LDAP users don't get registered as managed users.

Option 3

Create a single SCIM Directory configuration for both your ldap users and your external users.  CPE will query your IDP via SCIM for your users and the groups they belong to.  You can manage authorization using the groups you define in your IDP.  For example, your ldap users could be in one or more groups and you assign those groups different privileges in CPE.  You external users could also be defined in one or more groups in your IDP and you can perhaps assign more restrictive privileges to those groups in CPE.

I have configured WAS V9.0.5.21 TRAD (CPE V5.6.0) with the setup of OIDC to support external idp Okta. We do not use Content Navigator, only FileNet API.

The OIDC config is setup and working but when we go to use the OpenTokenCredentials API we do not get access to FileNet. We are passing in the email address using claim 'sub'. Our test user in LDAP does have the same email. How do we map idp identity to user in LDAP? Some users will be in LDAP, some won't.

As a workaround, we added a Managed Directory Configuration in Acce (adding email domain from idp) and added the user to the Managed User Realm (default state = Provisioned) and we were able to use the OpenTokenCredentials API to get access to FileNet without issue via #authenticatedusers

I understand the Managed Directory Config approach to be applicable only to ICN where user starts as provisioned then moves to Confirmed by means of Identity Rule either Allow/Allow Self registration so while we have it working it can't be the final approach as there are hundreds of external users so we can't add them manually.

The users in the idp are/will be in the local LDAP but some may not be so we need to handle both user registry users in idp (matching somehow) and some who are not.

Has anyone achieved what we are trying to do or does anyone have any guidance on the access to the CPE portion which is where the issue lies.

We have these properties below setup in the WAS for OIDC in the interceptor. Are we missing something here to make it work?

We also understand the property named mapIdentityToRegistryUser to only be applicable to ICN use cases so haven't gone that path. We also don't have any other property in the idp other than email so our scope is set to openid email.

Any help or guidance would be most appreciaated.

Hi Kenny,

You sent me an email via this community web site, but I don't seem to be able to respond to it.  So adding my reply here.

The problem is not the OIDC RelyingParty interceptor settings in WebSphere.  The problem is the Managed User interface, which was really built to be used by ICN which interacts with the CmManagedUser API to create new managed users, as needed, since it typically requires user consent to agree to have an account created.  Hence, sending a CE API request using the OpenTokenCredentials API for a new user will not automatically create that user, after all, even if you do have the "Allow Self-Register" identity rule set.  Sorry, I was incorrect in my original assessment, since this has not been attempted before.

Your best bet is to use the SCIM option I described.  If you really want to pursue the Managed User approach for external users, you can use the CE CmManagedUser API directly to create these users, if they do not exist.  However, this could be a bit of work, since you would be re-implementing what was done by ICN.  You might consider engaging IBM Expert Labs if you need help with this approach.

How are you distinguishing users that are in your LDAP vs external users not in your LDAP that are authenticated by the same IDP?  Do all your LDAP users have the same email domain suffix, whereas your external users have different email domain suffixes?  If so, there are a few ways to handle this.

Option 1

Create two Managed User directories

• Managed User directory 1 would be for users in your ldap.  Create an Allow Self Register identity rule containing the email domain suffix for these users
• Managed User directory 2 would be for your external users.  If you have a fixed set of email domain suffixes, then you can create Allow Self Register identity rules for each email domain.  Worst case is that you create Allow Self Register identity rules for each top-level domain name (i.e. "com", "edu", "gov", etc.)

Note that since you are not using ICN, all users who self-register in this fashion will remain in the "provisional" status.  The only way to get them into the "confirmed" status is if they login via ICN.  However, users in the "provisional" status can still be authorized and assigned to the security of documents/folders/etc. in the normal fashion.  The only caveat is that users in the "provisional" status are subject to be automatically removed based on the "Unconfirmed User Cleanup Interval Days" property of the Managed User Directory configuration.  However, is you set this property to 0, then that will disable this automatic cleanup.

Option 2

Create LDAP directory and a Managed User Directory

• The LDAP directory would be for your users in the LDAP
• The Managed User Directory would be the same as described in Option 1 for external users, except also add a Block identity rule for your ldap users, so that your LDAP users don't get registered as managed users.

Option 3

Create a single SCIM Directory configuration for both your ldap users and your external users.  CPE will query your IDP via SCIM for your users and the groups they belong to.  You can manage authorization using the groups you define in your IDP.  For example, your ldap users could be in one or more groups and you assign those groups different privileges in CPE.  You external users could also be defined in one or more groups in your IDP and you can perhaps assign more restrictive privileges to those groups in CPE.

I have configured WAS V9.0.5.21 TRAD (CPE V5.6.0) with the setup of OIDC to support external idp Okta. We do not use Content Navigator, only FileNet API.

The OIDC config is setup and working but when we go to use the OpenTokenCredentials API we do not get access to FileNet. We are passing in the email address using claim 'sub'. Our test user in LDAP does have the same email. How do we map idp identity to user in LDAP? Some users will be in LDAP, some won't.

As a workaround, we added a Managed Directory Configuration in Acce (adding email domain from idp) and added the user to the Managed User Realm (default state = Provisioned) and we were able to use the OpenTokenCredentials API to get access to FileNet without issue via #authenticatedusers

I understand the Managed Directory Config approach to be applicable only to ICN where user starts as provisioned then moves to Confirmed by means of Identity Rule either Allow/Allow Self registration so while we have it working it can't be the final approach as there are hundreds of external users so we can't add them manually.

The users in the idp are/will be in the local LDAP but some may not be so we need to handle both user registry users in idp (matching somehow) and some who are not.

Has anyone achieved what we are trying to do or does anyone have any guidance on the access to the CPE portion which is where the issue lies.

We have these properties below setup in the WAS for OIDC in the interceptor. Are we missing something here to make it work?

We also understand the property named mapIdentityToRegistryUser to only be applicable to ICN use cases so haven't gone that path. We also don't have any other property in the idp other than email so our scope is set to openid email.

Any help or guidance would be most appreciaated.

Hi Kenny,

You sent me an email via this community web site, but I don't seem to be able to respond to it.  So adding my reply here.

The problem is not the OIDC RelyingParty interceptor settings in WebSphere.  The problem is the Managed User interface, which was really built to be used by ICN which interacts with the CmManagedUser API to create new managed users, as needed, since it typically requires user consent to agree to have an account created.  Hence, sending a CE API request using the OpenTokenCredentials API for a new user will not automatically create that user, after all, even if you do have the "Allow Self-Register" identity rule set.  Sorry, I was incorrect in my original assessment, since this has not been attempted before.

Your best bet is to use the SCIM option I described.  If you really want to pursue the Managed User approach for external users, you can use the CE CmManagedUser API directly to create these users, if they do not exist.  However, this could be a bit of work, since you would be re-implementing what was done by ICN.  You might consider engaging IBM Expert Labs if you need help with this approach.

How are you distinguishing users that are in your LDAP vs external users not in your LDAP that are authenticated by the same IDP?  Do all your LDAP users have the same email domain suffix, whereas your external users have different email domain suffixes?  If so, there are a few ways to handle this.

Option 1

Create two Managed User directories

• Managed User directory 1 would be for users in your ldap.  Create an Allow Self Register identity rule containing the email domain suffix for these users
• Managed User directory 2 would be for your external users.  If you have a fixed set of email domain suffixes, then you can create Allow Self Register identity rules for each email domain.  Worst case is that you create Allow Self Register identity rules for each top-level domain name (i.e. "com", "edu", "gov", etc.)

Note that since you are not using ICN, all users who self-register in this fashion will remain in the "provisional" status.  The only way to get them into the "confirmed" status is if they login via ICN.  However, users in the "provisional" status can still be authorized and assigned to the security of documents/folders/etc. in the normal fashion.  The only caveat is that users in the "provisional" status are subject to be automatically removed based on the "Unconfirmed User Cleanup Interval Days" property of the Managed User Directory configuration.  However, is you set this property to 0, then that will disable this automatic cleanup.

Option 2

Create LDAP directory and a Managed User Directory

• The LDAP directory would be for your users in the LDAP
• The Managed User Directory would be the same as described in Option 1 for external users, except also add a Block identity rule for your ldap users, so that your LDAP users don't get registered as managed users.

Option 3

Create a single SCIM Directory configuration for both your ldap users and your external users.  CPE will query your IDP via SCIM for your users and the groups they belong to.  You can manage authorization using the groups you define in your IDP.  For example, your ldap users could be in one or more groups and you assign those groups different privileges in CPE.  You external users could also be defined in one or more groups in your IDP and you can perhaps assign more restrictive privileges to those groups in CPE.

I have configured WAS V9.0.5.21 TRAD (CPE V5.6.0) with the setup of OIDC to support external idp Okta. We do not use Content Navigator, only FileNet API.

The OIDC config is setup and working but when we go to use the OpenTokenCredentials API we do not get access to FileNet. We are passing in the email address using claim 'sub'. Our test user in LDAP does have the same email. How do we map idp identity to user in LDAP? Some users will be in LDAP, some won't.

As a workaround, we added a Managed Directory Configuration in Acce (adding email domain from idp) and added the user to the Managed User Realm (default state = Provisioned) and we were able to use the OpenTokenCredentials API to get access to FileNet without issue via #authenticatedusers

I understand the Managed Directory Config approach to be applicable only to ICN where user starts as provisioned then moves to Confirmed by means of Identity Rule either Allow/Allow Self registration so while we have it working it can't be the final approach as there are hundreds of external users so we can't add them manually.

The users in the idp are/will be in the local LDAP but some may not be so we need to handle both user registry users in idp (matching somehow) and some who are not.

Has anyone achieved what we are trying to do or does anyone have any guidance on the access to the CPE portion which is where the issue lies.

We have these properties below setup in the WAS for OIDC in the interceptor. Are we missing something here to make it work?

We also understand the property named mapIdentityToRegistryUser to only be applicable to ICN use cases so haven't gone that path. We also don't have any other property in the idp other than email so our scope is set to openid email.

Any help or guidance would be most appreciaated.

Thanks Roger

If we wanted to leave the LDAP Directory as is for internal users could we add a SCIM directory purely for the externals or do we really need to have them all in one directory?

Thanks, Kenny

Hi Kenny,

You sent me an email via this community web site, but I don't seem to be able to respond to it.  So adding my reply here.

The problem is not the OIDC RelyingParty interceptor settings in WebSphere.  The problem is the Managed User interface, which was really built to be used by ICN which interacts with the CmManagedUser API to create new managed users, as needed, since it typically requires user consent to agree to have an account created.  Hence, sending a CE API request using the OpenTokenCredentials API for a new user will not automatically create that user, after all, even if you do have the "Allow Self-Register" identity rule set.  Sorry, I was incorrect in my original assessment, since this has not been attempted before.

Your best bet is to use the SCIM option I described.  If you really want to pursue the Managed User approach for external users, you can use the CE CmManagedUser API directly to create these users, if they do not exist.  However, this could be a bit of work, since you would be re-implementing what was done by ICN.  You might consider engaging IBM Expert Labs if you need help with this approach.

How are you distinguishing users that are in your LDAP vs external users not in your LDAP that are authenticated by the same IDP?  Do all your LDAP users have the same email domain suffix, whereas your external users have different email domain suffixes?  If so, there are a few ways to handle this.

Option 1

Create two Managed User directories

• Managed User directory 1 would be for users in your ldap.  Create an Allow Self Register identity rule containing the email domain suffix for these users
• Managed User directory 2 would be for your external users.  If you have a fixed set of email domain suffixes, then you can create Allow Self Register identity rules for each email domain.  Worst case is that you create Allow Self Register identity rules for each top-level domain name (i.e. "com", "edu", "gov", etc.)

Note that since you are not using ICN, all users who self-register in this fashion will remain in the "provisional" status.  The only way to get them into the "confirmed" status is if they login via ICN.  However, users in the "provisional" status can still be authorized and assigned to the security of documents/folders/etc. in the normal fashion.  The only caveat is that users in the "provisional" status are subject to be automatically removed based on the "Unconfirmed User Cleanup Interval Days" property of the Managed User Directory configuration.  However, is you set this property to 0, then that will disable this automatic cleanup.

Option 2

Create LDAP directory and a Managed User Directory

• The LDAP directory would be for your users in the LDAP
• The Managed User Directory would be the same as described in Option 1 for external users, except also add a Block identity rule for your ldap users, so that your LDAP users don't get registered as managed users.

Option 3

Create a single SCIM Directory configuration for both your ldap users and your external users.  CPE will query your IDP via SCIM for your users and the groups they belong to.  You can manage authorization using the groups you define in your IDP.  For example, your ldap users could be in one or more groups and you assign those groups different privileges in CPE.  You external users could also be defined in one or more groups in your IDP and you can perhaps assign more restrictive privileges to those groups in CPE.

I have configured WAS V9.0.5.21 TRAD (CPE V5.6.0) with the setup of OIDC to support external idp Okta. We do not use Content Navigator, only FileNet API.

The OIDC config is setup and working but when we go to use the OpenTokenCredentials API we do not get access to FileNet. We are passing in the email address using claim 'sub'. Our test user in LDAP does have the same email. How do we map idp identity to user in LDAP? Some users will be in LDAP, some won't.

As a workaround, we added a Managed Directory Configuration in Acce (adding email domain from idp) and added the user to the Managed User Realm (default state = Provisioned) and we were able to use the OpenTokenCredentials API to get access to FileNet without issue via #authenticatedusers

I understand the Managed Directory Config approach to be applicable only to ICN where user starts as provisioned then moves to Confirmed by means of Identity Rule either Allow/Allow Self registration so while we have it working it can't be the final approach as there are hundreds of external users so we can't add them manually.

The users in the idp are/will be in the local LDAP but some may not be so we need to handle both user registry users in idp (matching somehow) and some who are not.

Has anyone achieved what we are trying to do or does anyone have any guidance on the access to the CPE portion which is where the issue lies.

We have these properties below setup in the WAS for OIDC in the interceptor. Are we missing something here to make it work?

We also understand the property named mapIdentityToRegistryUser to only be applicable to ICN use cases so haven't gone that path. We also don't have any other property in the idp other than email so our scope is set to openid email.

Any help or guidance would be most appreciaated.