Hello,
I'm hoping to get information from anyone who uses single sign-on with TNEW. We at New York University (NYU) use a single sign-on authentication (Duo Two Factor) to verify students, faculty, and staff when accessing various applications, but currently we don't have that integrated with TNEW. Basically, NYU community members have to access tickets via a different site in order to access promo-embedded links, after which they then have to log in to a TNEW account/create guest checkout to complete their order. We want them to only have to log in once. Can anyone point me to documentation/share what's worked for them? Your input is sincerely appreciated!
Thank you,
Emily
I believe Gawain Lavers has some experience with this kind of student login flow, but I'm not certain of the method of that implementation.
The approach I would want to take (someday, maybe, at ye olde Barde College) to accomplish a true single-sign-on experience would involve writing a small custom web service to handle your student logins. You would modify the TNEW login page to redirect students to the custom web service (which would display the NYU single sign on), the custom service would talk to the Tessitura API to identify or create a Tessitura account to match the student's account, and log the web session into that account, and then would immediately send the student back to TNEW using the shared session feature so they could continue using TNEW with that logged-in session.
I do. We take a very different approach, currently. Our main interest in authenticating UC constituents is in vending UC discounted tickets. Although I've built the system to allow a few different constituencies to be recognized and flagged, currently our only requirement is authentication for the UCB Student Discount, as it is very steep (50%) and covers almost all of our inventory.
We initially assumed we'd tie the campus SSO into our Tessitura login/account system, but there are clearly a lot of wrinkles that would have to be worked out, such as pre-existing accounts, what to do with SSO created accounts when a student or employee leaves, etc. One very major issue for us was that it was possible that someone would want to include UCB Student Discount tickets if they happened to be a parent, or if multiple students wanted to purchase tickets within the same order (both actually very common scenarios).
What we decided to do instead was to intercept sale of those tickets, go to the Pre-Cart page, and require a number of separate authentications based on the price types in the reservation. That way a student could sit in on their parent's ticket purchase, or a student couple could authenticate consecutively in order to put in an order for two discounted tickets.
The authentications simply last as long as the online purchase session, and we do not need to do the overhead of syncing accounts or overloading the login process.
If our customer base was almost exclusively faculty, staff, students and alumni, then perhaps we'd be interested in such a feature (Athletics pulls down the entire campus constituent LDAP database nightly, I think), but it is really a fairly modest percentage. The only place where it causes us a little trouble is in trying to do campus targeted mailings, but there are built in campus lists that we can use for that purpose.