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...
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.