@Scott Exton Thanks for the reply.  A couple questions:

1. If using the federated SSO OIDC authentication, is the local admin user (on a container model) the only account that can get in if this federation breaks?  Meaning, can it fall back to LDAP authentication (assuming not since that screen disappears) or can we setup multiple local "admin" users via the System Settings Account Management page.
   
   
2. For LMI REST API usage, does the OIDC token get passed each time?  Or how does REST API usage work after SSO is enabled?

Thanks Scott!

Matt

Hi Matt,

1. Yes if the OIDC OP cannot be contacted then console access with the local admin account is the fallback. You cannot combine OIDC and LDAP auth.

2. You can use the "Bearer" authorization header in each request instead of the Basic you would normally use to authenticate for rest api requests. I have an example in my blog https://community.ibm.com/community/user/blogs/lachlan-james-gleeson1/2025/06/23/verify-identity-access-lmi-sso

@Scott Exton Thanks for the reply.  A couple questions:

1. If using the federated SSO OIDC authentication, is the local admin user (on a container model) the only account that can get in if this federation breaks?  Meaning, can it fall back to LDAP authentication (assuming not since that screen disappears) or can we setup multiple local "admin" users via the System Settings Account Management page.
   
   
2. For LMI REST API usage, does the OIDC token get passed each time?  Or how does REST API usage work after SSO is enabled?

Thanks Scott!

Matt

@Lachlan James Gleeson Thank you for the detailed explanation.  I have a few questions based on your blog:

1. In the blog you mention there is no backout from the OIDC configuration on containers if the OP fails, and it mentions on the virtual appliances the local admin account won't work with the OIDC solution configured.  In your response here, you indicated the local admin would work if the OIDC OP failed.  Does it in fact work, assuming we used admin@local to authenticate?  Also, would other locally defined accounts in the LMI account management be able to authenticate this way?
   
   
2. Your blog states incoming users have to be mapped to existing users in the LMI.  Is there any way around this?  This is essentially account impersonation which is heavily frowned on.  When things are done in the LMI, we want audit records saying jdoe1234 made the change.  But I cannot define all the users that would access the LMI as we have one team that uses the policy administration GUI routinely where the members of that team are subject to change.
   
   
3. The blog also states that groups cannot be used.  I see someone left a comment mid last year about asking if the groups could be used to control access.  Do you know if this is a planned enhancement for a later date?  It goes back to my question in #2, because if impersonation is not used, and any user is allowed to authenticate (like with LDAP), then the groups would need to control access.
   
   
4. Is there any way to debug that mapping rule that is used for the token mapping?  For example, a way to print out the contents of the incoming token, and to send debug messages to the config container stdout (console logs) or LMI trace logs?

Also, on a side note I was looking at your documentation for ibmvia-autoconf which says it uses pyIVIA.  Is that something internal to IBM, or is that an officially supported tool to manage IVIA configuration?  That looks like it could be really useful.

Thanks again, much appreciated!

Matt

Hi Matt,

1. Yes if the OIDC OP cannot be contacted then console access with the local admin account is the fallback. You cannot combine OIDC and LDAP auth.

2. You can use the "Bearer" authorization header in each request instead of the Basic you would normally use to authenticate for rest api requests. I have an example in my blog https://community.ibm.com/community/user/blogs/lachlan-james-gleeson1/2025/06/23/verify-identity-access-lmi-sso

@Scott Exton Thanks for the reply.  A couple questions:

1. If using the federated SSO OIDC authentication, is the local admin user (on a container model) the only account that can get in if this federation breaks?  Meaning, can it fall back to LDAP authentication (assuming not since that screen disappears) or can we setup multiple local "admin" users via the System Settings Account Management page.
   
   
2. For LMI REST API usage, does the OIDC token get passed each time?  Or how does REST API usage work after SSO is enabled?

Thanks Scott!

Matt

1. The console process for appliances has a tool to 'reset' the authentication to the local user registry. In containers, if the config container starts you can just exec a shell process and run the same command. AFAIK this only works for the admin local user

2. The blog refers the the fine-grained management authorization feature of IVIA. If you are satisfied with simple group membership permits access (or even a valid token permits access), you can use those config options in the LMI (which will be audited as the configured claim from the token)

3. This is something the dev team is considering but no committed version yet

4. I did not think this was supported but I just checked the code an you are permitted to use java.lang.System.out.print but I do not know where it would end up...my guess is message/trace log

both ibmvia-autoconf and pyivia are only maintained by myself and another colleague. I don't think I can claim it is 'ibm supported' but the ivia dev team has an interest in maintaining it for the moment. If you have question or suggestion feel free to reach out or open an issue in the public git.

@Lachlan James Gleeson Thank you for the detailed explanation.  I have a few questions based on your blog:

1. In the blog you mention there is no backout from the OIDC configuration on containers if the OP fails, and it mentions on the virtual appliances the local admin account won't work with the OIDC solution configured.  In your response here, you indicated the local admin would work if the OIDC OP failed.  Does it in fact work, assuming we used admin@local to authenticate?  Also, would other locally defined accounts in the LMI account management be able to authenticate this way?
   
   
2. Your blog states incoming users have to be mapped to existing users in the LMI.  Is there any way around this?  This is essentially account impersonation which is heavily frowned on.  When things are done in the LMI, we want audit records saying jdoe1234 made the change.  But I cannot define all the users that would access the LMI as we have one team that uses the policy administration GUI routinely where the members of that team are subject to change.
   
   
3. The blog also states that groups cannot be used.  I see someone left a comment mid last year about asking if the groups could be used to control access.  Do you know if this is a planned enhancement for a later date?  It goes back to my question in #2, because if impersonation is not used, and any user is allowed to authenticate (like with LDAP), then the groups would need to control access.
   
   
4. Is there any way to debug that mapping rule that is used for the token mapping?  For example, a way to print out the contents of the incoming token, and to send debug messages to the config container stdout (console logs) or LMI trace logs?

Also, on a side note I was looking at your documentation for ibmvia-autoconf which says it uses pyIVIA.  Is that something internal to IBM, or is that an officially supported tool to manage IVIA configuration?  That looks like it could be really useful.

Thanks again, much appreciated!

Matt

Hi Matt,

1. Yes if the OIDC OP cannot be contacted then console access with the local admin account is the fallback. You cannot combine OIDC and LDAP auth.

2. You can use the "Bearer" authorization header in each request instead of the Basic you would normally use to authenticate for rest api requests. I have an example in my blog https://community.ibm.com/community/user/blogs/lachlan-james-gleeson1/2025/06/23/verify-identity-access-lmi-sso

@Scott Exton Thanks for the reply.  A couple questions:

1. If using the federated SSO OIDC authentication, is the local admin user (on a container model) the only account that can get in if this federation breaks?  Meaning, can it fall back to LDAP authentication (assuming not since that screen disappears) or can we setup multiple local "admin" users via the System Settings Account Management page.
   
   
2. For LMI REST API usage, does the OIDC token get passed each time?  Or how does REST API usage work after SSO is enabled?

Thanks Scott!

Matt