Investigate Queens SSO Integration

[pR0Ps]

Queen's allows for web applications to use their SSO service. However, the SSO page (below) states this is for faculty and staff only. This could maybe be dealt with by getting a member of faculty to sponsor us.

The page also mentions there are costs involved. I'm reasonably familiar with SAML-based SSO and I was under the impression that we would be doing most of the work and the actual SSO site would just be doing authentication and returning user data. I fail to see how this takes the 5 - 12 hours listed on their site, but maybe the configuration on their end is complicated?

Links: http://www.queensu.ca/its/caas/sso.html https://wiki.queensu.ca/display/itsd/Single+Sign-On

[ChrisCooper]

Cool. That would be lovely to have, and probably allow us to do some cool stuff.

[ChrisCooper]

Faculty sponsor would be an overall positive thing as well, lol.

[mystor]

What would the purpose of using SSO be? The only benefit I see is that it would use the same login information as SOLUS, sort-of like any other oAuth provider. The costs of implementing this queens specific single sign on system seems like it would be high, and it also means that logins for Qcumber would have to be done through Queen's lackluster, mobile-unoptimized, login page.

Personally, I feel like sticking to a separate login system, probably a standard username-password system or something neat like Persona, would be a better idea.

P.S. I don't think that this would let us access user data on SOLUS, in the same way that logging in to a website with your google account doesn't let you access that person's gmail.

[mystor]

This: https://wiki.queensu.ca/display/itsd/Single+Sign-On+Attributes is all of the data which we would be able to get: a deliverable Queensu email (many people don't check these anyways, we would want primary emails), NetID (Why would we want this?), Student ID (Again, why would we want this?), role at Queen's (student, faculty, etc... We could use a dropdown if we want to customize the site for each specific role), and the person's name (Kinda nice, but ultimately unnecessary)

[ChrisCooper]

This is all true. The upsides I see are:

1) look more official both from a faculty/admin view, and from a student view 2) be closer to real integration with Queen's systems, in case we move more that way in the future 3) validates queen's membership for things like reviews and ratings, preventing multiple accounts/invalid accounts/spam 4) the tailoring thing you mentioned (plus verification, so we can trust accounts as course owners without manual work)

P.S. I love how the example for the queens id contradicts itself:

• a single valued attribute, always 8 numerical digits
• the Employee ID or Student ID preceded by 'S' for student, 'E' for employee
• example: S1234567

On Wed, Nov 6, 2013 at 11:19 PM, Michael Layzell notifications@github.comwrote:

This: https://wiki.queensu.ca/display/itsd/Single+Sign-On+Attributes is all of the data which we would be able to get: a deliverable Queensu email (many people don't check these anyways, we would want primary emails), NetID (Why would we want this?), Student ID (Again, why would we want this?), role at Queen's (student, faculty, etc... We could use a dropdown if we want to customize the site for each specific role), and the person's name (Kinda nice, but ultimately unnecessary)

— Reply to this email directly or view it on GitHubhttps://github.com/ChrisCooper/QcumberD/issues/93#issuecomment-27936908 .

[mystor]

Well, student id's did used to be 7 digits, and documentation is hard.

I can understand these advantages, but I am worried about the difficulties in implementing it. I would say look deeper, but don't be sad if it doesn't work out. On 2013-11-06 11:28 PM, "Chris Cooper" notifications@github.com wrote:

This is all true. The upsides I see are:

1) look more official both from a faculty/admin view, and from a student view 2) be closer to real integration with Queen's systems, in case we move more that way in the future 3) validates queen's membership for things like reviews and ratings, preventing multiple accounts/invalid accounts/spam 4) the tailoring thing you mentioned (plus verification, so we can trust accounts as course owners without manual work)

P.S. I love how the example for the queens id contradicts itself:

• a single valued attribute, always 8 numerical digits
• the Employee ID or Student ID preceded by 'S' for student, 'E' for employee
• example: S1234567

On Wed, Nov 6, 2013 at 11:19 PM, Michael Layzell notifications@github.comwrote:

This: https://wiki.queensu.ca/display/itsd/Single+Sign-On+Attributes is all of the data which we would be able to get: a deliverable Queensu email (many people don't check these anyways, we would want primary emails), NetID (Why would we want this?), Student ID (Again, why would we want this?), role at Queen's (student, faculty, etc... We could use a dropdown if we want to customize the site for each specific role), and the person's name (Kinda nice, but ultimately unnecessary)

— Reply to this email directly or view it on GitHub< https://github.com/ChrisCooper/QcumberD/issues/93#issuecomment-27936908> .

— Reply to this email directly or view it on GitHubhttps://github.com/ChrisCooper/QcumberD/issues/93#issuecomment-27937157 .

[pR0Ps]

Queensu email (many people don't check these anyways, we would want primary emails)

I don't know about that. As a student, it's an huge issue if you don't check your student email. Plus, we wouldn't really be using it for anything. If we did, it would be for school-related things, which personally, I would want going to my school account anyway.

The cost of integrating Queen's SSO into Qcumber should be on par with OAuth and other login protocols. Queen's uses a fairly standard SAML 2.0 based SSO, which Django plugins exist for.

The fact that the login page is ugly is irrelevant, it's an official Queen's thing. By using it, we instantly gain a TON of credibility and don't ever have to deal with spammers, anonymous idiots, sock puppets, or any other garbage like that.

The only people that would be able to log in would be verified Queen's students/faculty. In addition, this completely gets rid of the difficulty in getting people to sign up for things. They would just log in like they do for every other Queen's service.

Going this route, we also wouldn't be responsible for keeping any user data safe. The SSO page would take care of all the risky stuff like (hopefully hashed) password storage, security issues (people trying to break in to your account) and the like.

[mystor]

That could be very nice. I was mostly worried about the IT time which was talked about on the website you linked.

What professor do you think would sponsor us to apply? On 2013-11-07 12:29 AM, "Carey Metcalfe" notifications@github.com wrote:

Queensu email (many people don't check these anyways, we would want primary emails)

I don't know about that. As a student, it's an huge issue if you don't check your student email. Plus, we wouldn't really be using it for anything. If we did, it would be for school-related things, which personally, I would want going to my school account anyway.

The cost of integrating Queen's SSO into Qcumber should be on par with OAuth and other login protocols. Queen's uses a fairly standard SAML 2.0 based SSO, which Django plugins exist for.

The fact that the login page is ugly is irrelevant, it's an official Queen's thing. By using it, we instantly gain a TON of credibility and don't ever have to deal with spammers, anonymous idiots, sock puppets, or any other garbage like that.

The only people that would be able to log in would be verified Queen's students/faculty. In addition, this completely gets rid of the difficulty in getting people to sign up for things. They would just log in like they do for every other Queen's service.

Going this route, we also wouldn't be responsible for keeping any user data safe. The SSO page would take care of all the risky stuff like (hopefully hashed) password storage, security issues (people trying to break in to your account) and the like.

— Reply to this email directly or view it on GitHubhttps://github.com/ChrisCooper/QcumberD/issues/93#issuecomment-27938811 .

[pR0Ps]

I talked to a computing prof today and he said that he would be open to sponsoring us. In addition @ChrisCooper , you said you were in contact with a prof last year right?

[mystor]

That would be super awesome.

If we get this, it may also discourage the University from shutting us down if they decide scraping is bad, Which would be nice. On 2013-11-07 6:22 PM, "Carey Metcalfe" notifications@github.com wrote:

I talked to a computing prof today and he said that he would be open to sponsoring us. In addition @ChrisCooper https://github.com/ChrisCooper, you said you were in contact with a prof last year right?

— Reply to this email directly or view it on GitHubhttps://github.com/ChrisCooper/QcumberD/issues/93#issuecomment-28017196 .