Multipass SSO with unique_id and no email?
I've been trying to work out how our multipass SSO is going to work, and am having some trouble with a lack of explicit documentation. Can I authenticate users to tender using only their unique_id? Can I create new users view multipass with only a unique_id, and no email? We don't store email addresses in our LDAP, so while I can create a solution on our end to make sure an email is aways passed to tender for SSO, it would be nice if I could avoid that and just stick to the unique_id we use internally.
My last test of trying this threw a "We're sorry, but something went wrong" error (different from the "There must be an email, it must be valid, etc" error) so I'm not sure if there's something else going wrong or basically this use case isn't supported.
Discussions are closed to public comments.
If you need help with Tender please
start a new discussion.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by Courtenay on 18 Oct, 2013 12:11 AM
Hi!
Users do require an email address - that is how we communicate with them. It's kind of the core of Tender. You can probably make something fake, but then they will have to keep checking the site to see if there is any update to their discussion, which is kind of annoying to them.
I did not see any errors come in from your SSO tests; there is however in your settings/extras a SSO debugger you can use to copy/paste the generated string and ensure it is valid.
2 Posted by Kaitlyn Goodall on 21 Oct, 2013 11:34 PM
I would definitely want to make sure that users registered email accounts in our tender system. However, the email addresses they register in tender are not necessarily the email addresses they are provisioned through us, and we also don't store that information in our LDAP at the moment, due to FERPA concerns.
Since we are not storing their email addresses on our end as something we can say definitively belongs to a particular user through our authentication, I do not want to be using that information as part of their authentication: I only want it to be where they receive emails from tender. As such I don't want any flow where they would tender their email to us during each authentication. I also don't want to manage a lookup table on my end of email addresses to authenticated tokens, as that requires setting up an administrative panel if they ever want to change that email address used in tender.
Our ideal authent flow, and one that it seemed like it should be possible with multipass given the description of external_id, would be to pass a unique identifier token (as unique_id) to tender when we log a given user in or provision a new account in tender. They could then manage their email address separately in tender as they desired, which would be their responsibility. If necessary, when creating a new account I can add a step to the authent flow where they enter the email address they would prefer for the tender account, but I would still prefer to not be storing that data (the email address) and using it as the individual identifier for the user, if possible.
Right now, if I attempt to log a user in who does not already have an account in tender, it throws an error regarding the email being too short/not present. If the user already has an account in tender, it seems to work just fine with unique_id (&alternate_id set the same).
I can always try to find out if a user is already provisioned before sending the auth flow black to tender, and if they are not provisioned in tender, requesting an email address to pass along to tender for the provisioning. Given that this could potentially involve thousands of users, since it will be the support system for a university, and given that there doesn't seem to be a way to query tender for a specific user account with a specific external_id, it looks like I would have to retrieve and cache all user accounts on my end to be sure whether a user with a given external_id was already provisioned in tender or not.
From further testing, it also looks like the unique_id described in the multipass SSO documentation does not actually persist as the SSO external_id, but instead external_id also needs to be set. Once the user has an email address set in tender, logging them in with only the unique_id and alternate_id both set to their token seems to be working.
Support Staff 3 Posted by Courtenay on 22 Oct, 2013 09:25 AM
I just looked up the code; you can login users with just the external ID, but email addresses are always required for new accounts. You could probably send a http request for a given external id and check the result code to see if the user exists and if you need to ask them for an email address.
4 Posted by Kaitlyn Goodall on 22 Oct, 2013 04:10 PM
Thanks for confirming that, Courtenay!
Is there any documentation on which endpoint to call and how to call it to retrieve a single user by their external_id? the only documented API calls seem to either be all users (with paging) or an individual user based on user id, or the currently logged in user (I assume for calls made via JS).
(I tried seeing if the /users endpoint would accept a call with external_id passed to it as post data, and also as a url query string. The first case threw an error regarding the email and pass being blank--obviously it's only set up to act as the login user interface when called like that, and the second just returned the paged all users resource)
Support Staff 5 Posted by Courtenay on 23 Oct, 2013 08:11 AM
Well, I was suggesting something like a generic SSO post, where anything with a ?sso= string would either respond with redirect (in the case of success) or 200 (ok, invalid user)... effectively logging them in. I'm not sure how this would work if you were doing it client-side, though.
I wonder if it would make sense for me to add a 'redirect if no user found' clause so that if you send someone to tender it immediately sends them back to a custom URL which would allow them to enter their email address.. OR.. if no email address is sent, just ask them for it within tender.
6 Posted by Kaitlyn Goodall on 23 Oct, 2013 07:04 PM
Courtenay, I've been playing with this today and while it sounded promising, I get the same 302 (redirect) response from the ?sso GET request whether there is or isn't an email address, and whether or not the account already exists.
For now, I can create a database of tokens on my end and use that to assume that any new token not already in it needs to have a page requesting their email to pass to tender for account creation.
Moving forward, if you could implement either of those solutions, that would be fantastic, I'd really love that and especially in the case of the latter one it sounds like it would really help for cases where an organization would rather the user entirely manage their own email contact info with tender.
Even just having an option to return a status code other than 302 (maybe 422; it's gaining momentum in other services for similar situations where 401 might not be entirely appropriate and the request is essentially properly formed) for an SSO multipass with no email address for an user not already created, but properly returning a 302 redirect if the user DOES already exist (even with no email) would be a great step forward for this case; I know I would be perfectly content with that, personally.
Support Staff 7 Posted by Courtenay on 23 Oct, 2013 08:52 PM
OK, what I probably meant to say was: post to the api endpoint!
https://api.tenderapp.com/montanastate/?format=json&sso=SSO_STRING_HERE- that will render a 401 on fail or a 200 on success (with some basic json describing the various api utilities).8 Posted by Kaitlyn Goodall on 23 Oct, 2013 09:05 PM
Yay! That does make MUCH more sense... I must have glazed over it myself and assumed you meant the actual login endpoint since the SSO token authent pattern for the API was marked as deprecated. Whoops.
And that's working completely. Thank you so much, I can definitely just use that for now!
Support Staff 9 Posted by Courtenay on 23 Oct, 2013 09:07 PM
No, I was just not thinking. I had to look up the code to figure it out. Hope it all works for you. Open a new discussion if you have any more questions or requests :)
Courtenay closed this discussion on 23 Oct, 2013 09:07 PM.