Add Office365 as an OAUTH Provider

[BlackFenix2]

Is your feature request related to a problem? Please describe.
Using the Custom OAUTH Provider dialog i am unable to utilize Office 365 as a provider. The authentication does work but i cannot map the username field to the UPN since the '@' symbol is not allowed for users. This does work if i omit a username field but i would like to keep the usernames uniform for a SSO experience and to merge users.

Describe the solution you'd like
Create a OAUTH provider for Office365. This would be able to map the username by parsing the UPN string before the '@' symbol which is the valid samAccountName. The Full Name can be mapped by merging the 'given_name' and 'family_name' values. the E-mail address can be mapped straight form the upn.

Describe alternatives you've considered
I tried adding additional claims in the ID Token, Rocket.Chat cannot parse optional claims due to the structure of the JWT

Additional context
Just trying to keep this concern alive. A lot of companies use Office365 for SSO.

[luckenbach]

We use Office365/Azure ADFS authentication with RocketChat without issues.

[BlackFenix2]

can you show the rest of your config on rocket chat? what do you have setup for "Username field"? my authentication does work but the username is user@domain.com which is invalid for rocket.chat. i have 'upn' set for username field, what do you have setup?

i included a screenshot of my custom OAUTH settings omitting the id and secret fields.

FYI i have rocket.chat Cloud if that helps.

[luckenbach]

[BlackFenix2]

thats another configuration i also tried, my feature request was meant to bypass the need to create an initial username on the initial login. i also wanted to be able to merge users on rocket.chat with their Office365 counterparts. i cannot do this because rocket.chat cannot map the upn or unique_name fields to the email address

i included the office365 OAUTH JWT:
https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-code#jwt-token-claims

i can get SSO to work with Office365 using the above config but i would like to map the e-mail address to the userPrincipleName and the username to the SamAccountName.

[mrtreg]

Hi, I'm challenged by the same issue.

I would like a feature to "construct" the "Username field" to something like "Firstname.Lastname" with the OAuth data.

[BlackFenix2]

@Hudell I saw you self-assigned this issue, any comment?

[Hudell]

I plan on working on this soon, to have it ready for the next release.

[BlackFenix2]

@Hudell no problem, sorry if i sounded rude earlier. I appreciate you handling this request!

[unplugged216]

Has there been any traction on this? I am having difficulties with the same integration as we need to map email and user name or at least the email to the email field.

[BlackFenix2]

@zharding if you don't mind some manual labor you can fix the username once the user's office365 credentials are validated at least once. you have to manually edit the user's username and e-mail fields to emulate the SamAccountName rather than the UserPrinciplaName. i included a before/after with a test user below (i had to do this for everyone at work), just save the changes and the accounts will work cleaner without the conflicting '@' symbol. The rocket.chat server is smart enough to keep this user mapped to your Office365 login.

[BlackFenix2]

ay yo @Hudell. any update on this open issue? i'd like to get in on some of that Office365 SSO goodness!

[DaGrisa]

Hi, i have configured it like this and i get a "502 Bad Gateway" from nginx.
Do you had to change anything in the nginx config?

# Config from
# https://rocket.chat/docs/installation/manual-installation/configuring-ssl-reverse-proxy/
##

# Upstreams
upstream backend {
    server 127.0.0.1:3000;
}

# HTTP Redirect
server {
       listen         80;
       server_name    HOSTNAME;
       return         301 https://HOSTNAME;
}

# HTTPS Server
server {
    listen 443;
    server_name HOSTNAME;

    # You can increase the limit if your need to.
    client_max_body_size 200M;

    error_log /var/log/nginx/rocketchat.access.log;

    ssl on;
    ssl_certificate /etc/nginx/cert.crt;
    ssl_certificate_key /etc/nginx/cert.key;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # don’t use SSLv3 ref: POODLE

    location / {
        proxy_pass http://backend/;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_host;

        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forward-Proto http;
        proxy_set_header X-Nginx-Proxy true;

        proxy_redirect off;
        proxy_read_timeout 300;
    }
}

[BlackFenix2]

ay yo, i've been waiting for a year to get some Office365 SSO up in here.

@zharding to say that there was no traction on this issue is a grave understatement. 😭

[benkroeger]

This request would be solved with #15690
use {{/^(.+)@/::upn}} as value in the usernameField configuration. It will extract whatever is in the upn field before the @ character

[BlackFenix2]

@benkroeger If i add this value to my usernameField will i mess up other logged in users? if i change this setting i want to ensure the oauth logins still point to the correct rocket.chat user.

i saw that the PR #15690 is still in progress. that should solve my SSO issue once and for all!

[benkroeger]

the current implementation looks for existing users by username. this means, if you change the way the username is compiled on an existing custom oauth provider, you would not find existing users (although the same person might have an account already). That said, one could add another hook to check for existing users by email address. That would be a separate requirement and should be addressed in another PR.
I have no idea what is missing for #15690 to get any attention - so don't get your hopes up.