Integration of Single Sign On solution

[canasdiaz]

After a meeting with Hermina and Kang we (Bitergia) can start exploring the integration with the Single Sign On solution provided.

AFAIK (feedback from @hmitsch is welcome) the main requirement is allowing Mozilla guys to sync the access to Kibana with their user database.

The documentation provided is:

• https://github.com/mozilla-iam/testrp.security.allizom.org/tree/master/webserver_configurations/OpenID_Connect/Nginx
• https://testrp.security.allizom.org//

[canasdiaz]

@hmitsch we are ready to start configuring this, in case we have doubts who is the contact person?

[hmitsch]

That would be @gdestuynder.

[canasdiaz]

@gdestuynder hi! one of my workmates told me we need to know the endpoint where our nginx has to point in order to use the SSO authentication.

Can you help us with it?

[gdestuynder]

Hi @sanacl Note: we also have https://github.com/mozilla-iam/mozilla.oidc.accessproxy now in case that makes your deployment easier.

I believe that by endpoint, you mean the OIDC configuration for the proxy (discovery url, client id, client secret) - in which case, it's not actually me but the service owner on Mozilla side that files and handle the request.

@hmitsch if that's you, or someone you know, please point them to https://mana.mozilla.org/wiki/display/SECURITY/SSO+Request+Form and have them coordinate with Bitergia directly - this involves accesses and credentials thus it's not something we're going to solve in a public github issue

[hmitsch]

@gdestuynder thanks a lot, makes sense!

@flamingspaz would you be able to help with this? Or should I go ahead and file that SSO Request Form?

-Henrik

[canasdiaz]

@hmitsch @flamingspaz hi guys, what can we do to unblock this?

[flamingspaz]

I've submitted a request to get creds, ill send them over as soon as I get them.

[dpose]

Hi @hmitsch @flamingspaz @gdestuynder,

we have followed the documentation at https://github.com/mozilla-iam/testrp.security.allizom.org/tree/master/webserver_configurations/OpenID_Connect/Nginx to install and configure the proper modules for nginx and we have configured the virtualhost based on this example https://github.com/mozilla-iam/testrp.security.allizom.org/blob/master/webserver_configurations/OpenID_Connect/Nginx/conf.d/social_ldap_pwless.conf but we are getting the error below:

[error] 16619#0: *1 [lua] openidc.lua:424: openidc_discover(): accessing discovery url (https://auth-dev.mozilla.auth0.com/.well-known/openid-configuration) failed: no resolver defined to resolve "auth-dev.mozilla.auth0.com", client: 163.117.202.204, server: sso-analytics.mozilla.community, request: "GET /logout HTTP/1.1", host: "sso-analytics.mozilla.community"

Could you help us with it?

Best regards, David P.

[hmitsch]

From @flamingspaz:

re: the sso proxy you should use the url https://auth.mozilla.auth0.com/.well-known/openid-configuration

[dpose]

@hmitsch

Thanks for your quick answer. I tested it too and I got the same result...

[error] 16619#0: *1 [lua] openidc.lua:424: openidc_discover(): accessing discovery url (https://auth.mozilla.auth0.com/.well-known/openid-configuration) failed: no resolver defined to resolve "auth.mozilla.auth0.com", client: 163.117.202.204, server: sso-analytics.mozilla.community, request: "GET /logout HTTP/1.1", host: "sso-analytics.mozilla.community"

[flamingspaz]

Weird, it sounds like that might be a DNS issue. Can you do a dns lookup on the server for auth.mozilla.auth0.com and see if you get anything back?

Additionally, we've configured the URL as analytics.mozilla.community on our end, not sso-analytics. However I don't think that would cause this issue.

/cc @gdestuynder

[gdestuynder]

@dpose note that https://github.com/mozilla-iam/mozilla.oidc.accessproxy/tree/master/etc has the same kind of config as https://github.com/mozilla-iam/testrp.security.allizom.org/tree/master/webserver_configurations/OpenID_Connect/Nginx but is a little newer (we're in the process of cleaning that up, but it takes time)

Anyhow, make sure you have this line: https://github.com/mozilla-iam/mozilla.oidc.accessproxy/blob/master/etc/conf.d/nginx_lua.conf#L4

resolver 8.8.8.8 8.8.4.4;

And change the resolvers to your own DNS resolver if necessary (these are Google's public resolvers).

[canasdiaz]

Thanks to @flamingspaz we've already testing the configuration on our side.

According to my notes (please correct me if I'm wrong) the next steps are:

• Mozilla team: modify the access rule to allow the dashboard use the SSO
• Mozilla team: you guys tell us how we can test or access to the platform (we'll need it both for testing and for using it).

An a question, how are the roles managed?

[gdestuynder]

@sanacl the credentials you got allow the usage of SSO (no specific rule needed) There are 2 layers of authorization to access the system after that:

1) "we" enforce which kind of account can login (staff, community,all, etc.) - this is set when filling the SSO request form 2) "you" enforce finer grained access, and leverage access groups that are passed to you by the SSO system however works best for your use case. we can help understand the data passed in the profile (you can see all data for your profile at https://prod.testrp.security.allizom.org/ or directly from your client)

[hmitsch]

@gdestuynder @jdow

1. We want to have Staff + NDA'ed contributors to have access. Can you configure that?
2. There is no need for fine grained access inside Community Analytics at this moment.

[canasdiaz]

My mozilla.org username is https://mozillians.org/es/u/lcanas/

[canasdiaz]

@hmitsch "There is no need for fine grained access inside Community Analytics at this moment."

Going this way we would have only one group of users able to modify everything. Please confirm you are ok with this scenario so we can move forward when our accounts are created.

[hmitsch]

@sanacl yes, let’s do the same we do currently withhe difference of being properly integrated with Mozilla IAM.

[hmitsch]

@sanacl I just invited you to the NDA Group. Can you accept the terms and see if you can login using the nginx proxy?

[flamingspaz]

It should already be configured to allow staff + NDA users to log in. Lets test that out.

[dpose]

Hi @hmitsch my mozilla.org username is https://mozillians.org/en-US/u/dpose/

[flamingspaz]

Just to keep this ticket up to date:

Everything on the proxy side is set up and working. Right now we're waiting on the infosec team to re-enable sending groups with the login information, then it should all just work.

[canasdiaz]

@flamingspaz I just want to make sure the status is the same and we (Bitergia) are not blocking this. Thank you!

[flamingspaz]

Yes, the above update is still valid. On our end we need to send the correct groups.

[flamingspaz]

Actually, to add, there is still an outstanding issue where sessions are not set properly. This means the proxy works in Firefox, but not Chrome. Since I expect 99% of users will be using Firefox to access community analytics, we don't have to deal with this right now.

[gdestuynder]

Actually, to add, there is still an outstanding issue where sessions are not set properly. This means the proxy works in Firefox, but not Chrome. Since I expect 99% of users will be using Firefox to access community analytics, we don't have to deal with this right now.

@flamingspaz Do you have more details on this? I just logged in on https://social-ldap-pwless.testrp.security.allizom.org with Chrome (this also uses the nginx based proxy) without issue - but this worries me since a user agent shouldnt affect the session in theory

[canasdiaz]

@hmitsch @flamingspaz hey guys, I've just tested with my github account in a private firefox window and it did not work. Once a log into github and authorize Mozilla I see an error page. It says "something went wrong" and the url is https://sso.mozilla.com/forbidden

[flamingspaz]

It should be working now, the bitergia5 backdoor is still there though and needs to be disabled.

[canasdiaz]

@hmitsch @flamingspaz I've tested again with a private firefox window and I still get the same error.

What I do is:

• new private window
• go to analytics.mozilla.community
• log in using github account (it asks for user, passwd and code)
• I get the "something went wrong" error page

Am I missing something?

[canasdiaz]

@hmitsch @flamingspaz I've tested today doing the same and it finally works. Yippieeeee 💃

[canasdiaz]

@flamingspaz before decommissioning the secondary access used by the Bitergia staff I would like to be 100% sure of what our people here have to do in order to be able to access the dashboard. As far as I know:

• account in mozillians.org
• do we have to send you the new accounts?
• access the dashboard using the github account

[flamingspaz]

Those steps are correct yes, once they have made an account on mozillians.org we can add them to the correct group so they will get access. To be clear, the GitHub account they link will need 2FA enabled.

[canasdiaz]

I'm providing you a list of the Bitergians who need access asap.

[canasdiaz]

@flamingspaz List of Bitergians sent via email.

[hmitsch]

@sanacl I just invited all the people you had requested to the NDA group. @flamingspaz please decommission the secondary access at your convenience.

Best regards, Henrik

[hmitsch]

test

[canasdiaz]

Hey folks, can we close this ticket? We could create a new one to decommission the secondary access (BTW, we can do it and @flamingspaz can review this is done).

[hmitsch]

@sanacl I'd like to close this ticket only once we decommissioned secondary access. Please go ahead and remove the secondary access. Thank you!

[canasdiaz]

I've identified a change we need to query the ES database. We'll contact @flamingspaz during the day to agree a solution and execute it.

[hmitsch]

@sanacl please work with @johngian on implementing the solution to disable secondary access.

[canasdiaz]

We haven't progressed this week. The only thing we need to confirm is we disable only what we need to decommission the secondary URL we are using for the dashboard. I'll contact u next week to get that information @johngian

[dpose]

@hmitsch @sanacl @flamingspaz

We had an incident yesterday and we lost the container Yousef created for the SSO. After recovering the container and checking everything is working successfully again, I've taken the chance to automate the creation and configuration of the container to be able to recreate it from scratch in a few seconds with 0 effort using docker-compose. (thanks to this incident, now, we know how to update the configuration of the SSO for the dashboard and the ES endpoint - if needed - or recover the container if something happens to it again) The new docker-compose file and all config files needed to configure the SSO for analytics.mozilla.community can be found in this path: '/data/docker/containers/sso-mozilla/'. We are working on fixing the issue with the SSO and the ES endpoint to disable the secondary access as soon as possible.

[hmitsch]

@dpose I understand that @johngian worked with you on this last week. Is this issue solved?

Best regards, Henrik

[dpose]

@hmitsch @sanacl

yes, @johngian helped me to know the name of the 'allowed_groups' to make the SSO work properly again. It is fixed and working successfully since last Friday.

I've already updated the configuration to make the /data/ urls work properly (without using the SSO) and I've disabled the secondary access too.

Best regards.

[hmitsch]

@dpose that's great. Is there anything left to do on this ticket or should we close it?

[hmitsch]

@johngian do you know why auto-login is broken on Community Analytics? Is this a configuration flag we are missing in the IAM proxy?

[dpose]

@hmitsch

I think the goal of this ticket has been reached:

• Integration of the SSO solution for http://analytics.mozilla.community
• Keep '/data' urls working without the SSO solution
• Disable any alternative access to the dashboard

I think we are forgetting nothing and this ticket can be closed.