I am currently considering linking iTop to a secure authentication portal provided by a third party. Goal is to allow users to authenticate with SMS, Google Authenticator, app, smart card. I still need the details, but I expect that their service will return a login and token.
Now, I was reading up on https://www.itophub.io/wiki/page?id=latest%3Aadmin%3Auser_authentication_options . I noticed it's easy to change the variable which identifies the user. Something which surprised me, was that the example showed how to set a cookie with the username: ext_auth_variable => '$_COOKIE[\'auth_user\']',
I'm assuming I'll need to rely on either a cookie or on a session variable for my implementation goal.
Just the username would be fine if it's really authenticated by the webserver's backend (server variable) and immediately and properly processed; but not if it's done by setting a cookie. Doesn't this make it very easy to impersonate?
I'm considering two things: extend authent-external to support optional 'password' (or other form of authentication string) and still have iTop validate that combination. Default behavior would be the same as now (relying on only username); unless an ext_auth_pwd_variable is set. try to create a child class for 'external-user' to accomplish the same thing
Also, I'd like users to be redirected to this external login page if a user is unauthenticated. Right now this would probably mean altering LoginWebPage::login() rather than just configuring a setting?
I might look into adding these options once I get more info from the third party.
Would this be considered if I made a pull request?
Or is there a better alternative then what I wrote?
Update: if there's any interest, I have a branch for this feature. Still need to test it though.
Update 16th December: I actually have a feature branch ready to extend authent-external. Currently it's like this (but could be altered to 'authentication_string' or whatever).
If no variable is specified for password, it's the same as before. Only user name counts. User is automatically considered to be authenticated without any further verification.
If a variable is specified, iTop will validate the credentials. This prevents spoofing of the user variable if it's only kept in a cookie without any further validation...
If no URL is specified, iTop always shows its internal login form.
If a URL is specified AND 'external' is the only option, it will redirect to the external authentication portal.
Unless I'm mistaken, this functionality is not available yet?
Last edit: Jeffrey Bostoen 2018-12-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would such a pull request be welcomed, or do I need to change something from 'pwd' to 'token' ? As an extension of the UserExternal class (keeping the backward compatibility); or something different?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This won't be processed as a PR right now, we are only considering bug fixes and translations. If you would like it to be an enhancement, open a Ticket in Sourceforge.
Thanks! :)
Guillaume
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am currently considering linking iTop to a secure authentication portal provided by a third party. Goal is to allow users to authenticate with SMS, Google Authenticator, app, smart card. I still need the details, but I expect that their service will return a login and token.
Now, I was reading up on https://www.itophub.io/wiki/page?id=latest%3Aadmin%3Auser_authentication_options . I noticed it's easy to change the variable which identifies the user. Something which surprised me, was that the example showed how to set a cookie with the username:
ext_auth_variable => '$_COOKIE[\'auth_user\']',I'm assuming I'll need to rely on either a cookie or on a session variable for my implementation goal.
Just the username would be fine if it's really authenticated by the webserver's backend (server variable) and immediately and properly processed; but not if it's done by setting a cookie. Doesn't this make it very easy to impersonate?
I'm considering two things:
extend authent-external to support optional 'password' (or other form of authentication string) and still have iTop validate that combination. Default behavior would be the same as now (relying on only username); unless an ext_auth_pwd_variable is set.
try to create a child class for 'external-user' to accomplish the same thing
Also, I'd like users to be redirected to this external login page if a user is unauthenticated. Right now this would probably mean altering LoginWebPage::login() rather than just configuring a setting?
I might look into adding these options once I get more info from the third party.
Would this be considered if I made a pull request?
Or is there a better alternative then what I wrote?
Update: if there's any interest, I have a branch for this feature. Still need to test it though.
Update 16th December: I actually have a feature branch ready to extend authent-external. Currently it's like this (but could be altered to 'authentication_string' or whatever).
ext_auth_variable => '$_COOKIE[\'auth_user\']',ext_auth_pwd_variable => '$_COOKIE[\'auth_pwd\']',ext_auth_url => 'http://your-auth-portal.org',If no variable is specified for password, it's the same as before. Only user name counts. User is automatically considered to be authenticated without any further verification.
If a variable is specified, iTop will validate the credentials. This prevents spoofing of the user variable if it's only kept in a cookie without any further validation...
If no URL is specified, iTop always shows its internal login form.
If a URL is specified AND 'external' is the only option, it will redirect to the external authentication portal.
Unless I'm mistaken, this functionality is not available yet?
Last edit: Jeffrey Bostoen 2018-12-19
Would such a pull request be welcomed, or do I need to change something from 'pwd' to 'token' ? As an extension of the UserExternal class (keeping the backward compatibility); or something different?
Hi Jeffrey,
This won't be processed as a PR right now, we are only considering bug fixes and translations. If you would like it to be an enhancement, open a Ticket in Sourceforge.
Thanks! :)
Guillaume