We implemented BOBJ Enterprise Authentication, Trusted Authentication, and REMOTE_USER login.
However, there is 2 major issues that I don’t know how to resolve.
When I create a new user or re-enable a user, I set a temporary password and then select the option “User must change password at next logon”. However, REMOTE_USER login just bypasses the requirement to change the password.
With REMOTE_USER login, the requirement for users to reset their password every 60 days seem to be bypassed.
The key issue here is REMOTE_USER logins I think. For the very few users (client tool users) that login by typing a username and password they are prompted to change their password and have to obey the 60 day password change requirement. However, these requirements seem to be bypassed for everyone else that is logged into InfoView via remote_user.
The problem is that this will be a IT security concern for all usrs except the client tool users.
If someone knows the REMOTE_USER string for another user, they can simply input that value and login as someone else (since the PW is ignored). Having PWs not expire is not going to go over well with our security team.
They’re want REMOTE_USER which makes sense but PWs need to meet special requirements.
Isn’t there a workaround where we can leverage REMOTE_USER but not have PWs be ignored?
Also, is there a way to “gray out” the username field on the infoview login page? Because if someone wanted to be malicious, they could logout of their account and be presented w/ the login page. Then, they could just input someone elses REMOTE_USER info and then login under a different account…
Your users shouldn’t be able to spoof another user’s ID, but that depends on how the web server is detecting the remote user’s ID. How do you have that set up?
When I said the password is ignored, that’s only when TA is actually being used. If the Shared Secret is not provided, the normal logon page will be displayed. The password is also required when logging in to the desktop applications.
What we’ve done is set up each user with an Enterprise ID that’s used with TA for Infoview, as well as a WinAD alias that’s used for the desktop apps. We then wrote a web app to manage the creation of IDs. All user IDs are created with a randomly-generated password.
The username is a value from the cert that Apache retrieves. Then this is passed as the REMOTE_USER variable.
The problem is that value from the cert could be known by another user.
If I could set the InfoView username field as read-only then this wouldn’t be an issue.
90% of the time the user won’t even see the login page because of the REMOTE_USER login. However, if the person clicks the “Log Out” button on InfoView, then they are presented the login page.
How do you mean? On the logon page? If you’re always going to be logging in via SSO, then you can just disable that entry field to prevent it from appearing.
But even with the logonpage active, if users land there they will have to enter an ID and password. The password is only bypassed when processing a TA logon.
If you set all users’ passwords to a random value, you users will only be able to log in via SSO.
The infoview users should never need to provide their username and password.
That is why I at least wanted to make the username read-only on the infoview login page.
The login information would be known by other users. It’s a value from a certificate that is available via directories. The passwords are not known by most users. The only users that use their password is the few users that leverage the client tools.
This is very odd because of:
Passwords are still needed even with trusted authentication because of the client tools. TA allows people to login to infoview without a password via REMOTE_USER login.
However, if TA is enabled, the password expire feature gets disabled in infoview. This doesn’t make sense to me and seems like its a product flaw. Reason being, you still want your passwords to expire stricly because of the client tools.
If you have configured Trusted Authentication to use REMOTE_USER, then the only way someone can log in without a password is by first authenticating through the web server. If your users can log in to the web server as someone else, then Trusted Authentication will not provide any level of security for you.
Essentially, Trusted Authentication trusts that the provider of the user ID has already vetted the user. If that is insecure, then you should be asking for a password.
But they will expire – for the client tool. If a user with an expired password attempts to launch DeskI (in two-tier mode), they will be prompted for a new password. You are not prompted in Infoview when TA is in use simply because there is no password to change.
(BOB member since 2002-08-29)
(BOB member since 2002-08-29)