While excited about having windows authentication for our users (we're a RAMP client), I do have a question. As I understand it, the security settings for any user allow either windows authentication or the old SQL Server based authentication, but not both. If Windows authentication is chosen, the old SQL password and account associated with the Tessitura user are completely deleted. So far so good for logging in to the client while in the windows domain.
But what about remote services that use Tessitura User username and password? For instance:
1) TNEW Admin Portal
2) Web Reports
3) Tessitura on the Go
4) The entire REST API...
Once you convert a login to Windows authentication, you can pass your windows credentials to TRBO, TessituraWeb(On the Go), etc... Basically once the switch happens, all the Tessitura service backed applications will validate that user against the domain.
I see. Will we expect to keep "service" type accounts as SQL accounts then, i.e. accounts that are not associated with any Windows user?
The TNEW login was the one that dawned on me last night as being the one we might have difficulties with.I know as self hosted it wont have access to my windows domain for authentication.
Particularly with V7 of TNEW allowing in-place editing, with the editing happening in TNEW and not Tessitura was envisioning more users having to log in to that to edit the purchase path content.
The others were less of an issue as they are hosted on our domain and so have access for user authentication, but was on'y considering moving actual human users across to this as it is a time save for them.
Although without seeing a login screen wasn't sure where users selected with User group they used.
Mark
Mark Ridley said:The TNEW login was the one that dawned on me last night as being the one we might have difficulties with.I know as self hosted it wont have access to my windows domain for authentication.
Chuck was pretty clear that the original use case that this was built for was RAMP, and that they hadn't started work on considering other setups. That said, I would guess that the TNEW Admin was an API-driven tool. If that's the case, then I'd guess that if the API server was in your domain, then it might work. When we were locally hosted, though, none of our Tessitura machines were in the local domain for security reasons.
Mark Ridley said:Although without seeing a login screen wasn't sure where users selected with User group they used.
You don't initially: you always go in as your default Security Group. However, if you then go to "relogin", you will get a dialog that allows alternate Security Group selection.
Was more the fact that for the web based On the Go etc sounded like the browser was doing the authentication, which was why you had to enable it within Chrome and Firefox, and just passing through the authenticated username. Does this also work for sites outside your domain?
If it asking REST to do it then that is okay, although having an externally available web site with single factor authentication on it allowing testing of internal network credentials is not ideal.
Suspected it would be re-login, which for majority of users I have with that would work fine, just have to remind them it is an option as majority of my users were unaware of it.
I'm just guessing: certainly the utility of things like On the Go would be very low if you had to use a browser in your domain.
The single factor thing had, I think, dimly occurred to me in relation to the TNEW admin portal.
HI All,
Closing the loop on the TNEW question - When using Tessitura v15, both TNEW v6 and TNEW v7 would require users to have separate credentials used for TNEW's administration area if they have windows auth enabled for their Tessitura client credentials. The TNEW credentials would not have windows auth enabled.
We do have plans to update TNEW so that the same credentials can be used both in the admin portal and in Tessitura but are unsure about timing. It is likely that at v15 general release the solution will be to create a second set of credentials for use with the TNEW admin portal.
Thanks,
Chris Szalaj
Thanks for the clarification Chris.
As a RAMP client we would certainly wish to not just keep a unified login scheme (whatever it is) but also be able to extend our 2-factor authentication to those other remote logins. The PCI ramifications of things like Web Reports are of course not very significant, but with the TNEW admin there is obviously the peril of site hijacking. Are there any plans for this? And if TNEW admin is going to be effectively forked from our standard user credentials, and of course you have to support non-RAMP clients, we would happily suffer a second 2-factor system.
Hi Gawain, We have received a few requests for 2FA at TNEW admin login - we have it in our backlog, but no date or release yet planned for incorporating. We agree that it would be a good thing to have. Thanks for casting your vote, it helps -
Chris
CC Nara Zitner
Gawain,
After some testing and some updates, I'm happy to let the community know that the issue with TNEW and windows auth have been resolved, and the TNEW admin functions properly with the windows auth feature enabled.
Very cool!