feat: add single sign on feature using SAML #447
Conversation
openedx-webhooks
added
the
open-source-contribution
|
Thanks for the pull request, @RawanMatar89! What's next?Please work through the following steps to get your changes ready for engineering review: 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. 🔘 Let us know that your PR is ready for review:Who will review my changes?This repository is currently maintained by Where can I find more information?If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:
When can I expect my changes to be merged?Our goal is to get community contributions seen and reviewed as efficiently as possible. However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
|
@RawanMatar89 please rebase over openedx:develop, resolve conflicts and fix the failing tests like: |
RawanMatar89
force-pushed
the
SAML_SSO
branch
2 times, most recently
from
1980f5e
to
1cbee62
Compare
|
@volodymyr-chekyrta we have a big feature that we'd like to merge here: SAML SSO. I've assigned as a Reviewer, I understand you have other projects at hand so feel free to assign someone else. |
|
@volodymyr-chekyrta we have finished all the changes and test cases, kindly review this feature that we'd like to merge it |
|
@mphilbrick211 I've removed the |
|
@marcotuts thanks for having us yeterday. Would you mind sharing the next steps you suggest here? As discussed in the meeting, we'd love it if you can start with an Product Issue and give us few questions so we can explain our proposal more. @RawanMatar89 and I are happy to work with you on the product review and get this PR into a state where it's useful for everyone. |
|
Hi @OmarIthawi, here is a starting point for questions / product review details: 1 - As with other areas of the apps (Programs, Discovery, etc), we may want to think about Login / Registration as being either Native or Web. In this case, a mobile app build that wants to use SAML login could use the Web option since the Native tools do not have support for this (yet?). Doing this would avoid some of the UX issues detailed below that arise from having Web login appear in addition to the native login. 2 - I'm not clear how a mixed web / native login would work when a mobile app build has the "Learning Sites" feature enabled. This work is in discovery by @GlugovGrGlib, @volodymyr-chekyrta, and others, but including it here as an FYI in case the Web + Native login options doesn't align with the Learning Sites feature? (Note: Some of my smaller UX nits / notes / questions I will hold off on, since I think getting input on question 1 above is more important to determine first.) |
|
re: 1 @marcotuts We've done some research with a couple of community folks from both Backend and Mobile experience and found no native support for SAML. Unless we missed the obvious, it seems that this part has been set right. re: 2 "Learning Sites" which means multi-tenant mobile apps, right? At the moment SAML is configurable via standard static YAML configs. If the Learning Sites feature is to be built, I suspect it should provide some sort of configuration to instruct the application which login to show. The current SAML configuration is lightweight and considers mostly of three options:
Other configurable items can be supported such as jwt cookie name and others. |
|
@RawanMatar89 please check Marco's comment and let us know. |
Friendly ping on this, @RawanMatar89! |
|
@marcotuts Would you mind letting us know if anything else is needed for the product review? @RawanMatar89 and I have checked and there's not much we can add unless there are new points you'd like to discuss. cc: @mphilbrick211 |
|
Hi @OmarIthawi - Thanks for your earlier note regarding my earlier questions. From a product standpoint my suggestion is to not merge this as is, and instead merge an update to make it easy for the mobile app to configure native or webview. Separately once the plugin architecture is merged this specific customization could be done as a plugin, but enough UX / product questions remain in the double native + webview flow as presented above to not merge into the core apps. Additional detail / thoughts below for your review and input. 1 - Ideally it would be easy to choose between a Native vs a Web login path for the mobile app from a build configuration standpoint. The choice of native / webview should available for each mobile app build (or per learning site once the app supports this). This path would not give you the ability to show both native + web views simultaneously as shown in the PR above. This split avoids the dual path of having both a native + webview login option, each with their own configurable options for social / other mechanisms. If SAML login is required this and all forms of login / registration would be handled through the webview option instead of natively. 2 - The path of allowing both native + webview secondary mode is something that would still be possible to build as a plugin but I don't think this should merge in other than as the webview vs native selection described in part 1. There are various UX questions and concerns about the double Sign In + Sign in with SSO buttons shown in this PR, and questions about workflow for when registration / login mechanisms exist in both web + native views. 3 - There are apps that have ways to login from secondary mechanisms (ex: login with corporate email, login with domain name, etc. ) but these often are non-primary paths in the login experience, and are shown as secondary links somewhere on the login / register page (ex: Business Account login, Enterprise Login, Wholesale Account login, Use my school credentials, etc). How to handle these wider set of choices consistently seems difficult to handle simply / consistently, which is part of the reason for suggesting a plugin. Even in this plugin, I would probably suggest having only 1 primary CTA for sign-in, with other options being shown as secondary. That would at least echo some of the other apps with a "Secondary Webview Login" requirement. This way, any site that needs SSO as a primary mechanism can simply set up the app to use webview as the primary login mode. If a site has a secondary login path then this feature as a plugin could be enabled. Hopefully that helps, thanks @OmarIthawi for your patience I know this has been open for a long while now. |
|
Thanks @marcotuts for your input. I don't fully understand the points you've mentioned so I'll re-read and get back to you. What I understand, is that as-is it's not suitable to be merged upstream which I agree. Regarding the plugin extension, what's the ETA for that and is there any specs so @RawanMatar89 and I can contribute and work with you to move the ETA closer? We're planning to release multiple Open edX apps to the App Store with the following variations:
I see that your main concern is when more than one login method exists, which is fair. Therefore I'd like to learn more about the ideas you have in mind so we can push forward in aligned vision rather than trying to merge this pull request. |
|
@RawanMatar89 @marcotuts and @sdaitzman thanks for the discussion the other day on the product development. I'm writing the notes from the meeting:
We discussed other good-to-have features but won't be blocking this PR:
Depending on the configuration we should support the following variations (Figma file):
|
|
Dear @OmarIthawi , @marcotuts , @sdaitzman regarding our last discussion I do update the code to have the following:
please review it and let me know if there is anything missing |
|
Thanks @RawanMatar89, I've checked it and I think it checks all the boxes. @marcotuts @sdaitzman what do you think? |
|
@RawanMatar89 @OmarIthawi looks good to me! Just confirming, this currently doesn't include a configurable embedded webview to replace these native interface variants, right? (not a blocker as I understand it, just confirming) |
|
@sdaitzman I'm not really sure about that. The button opens an embedded WebView, however the WebView isn't opened by default when the app is shown if that's what you mean. cc: @RawanMatar89 |
Yes, that's basically what I mean; if it's straightforward/easy to implement, it would be great to include a configurable state that immediately embeds a WebView (open/visible by default) to allow for fully custom login screens (in addition to default native-only, native-and-SSO, and the SSO-only versions @RawanMatar89 showed above). Figma section showing two possible implementations of this on the right side: |
|
Understood @sdaitzman. I support this feature. For timing purposes, I'd like to avoid adding it to this pull request to make it easier to review. I'll discuss with @RawanMatar89 on the logistics. @volodymyr-chekyrta Kindly note that this pull request is ready for engineering review. |
|
Thanks @marcotuts. Well noted.
Ideally, yes. It shouldn't exist. However, some badly designed SSO providers forcibly include header, footer and so much more informaiton that it's a suprise to the user to include in a webview without giving them a chance to learn what's going to happen. SAML SSO is designed to work with low trust between independent parties and that means the mobile app developer has no control over the UI of the SAML SSO provider to make it more mobile friendly. I think it should exist.
I totally support the embedded option, but in our case and I suspect in many others it won't work. |
|
@volodymyr-chekyrta woud you be so kind and review this pull request? It's been blocked for a while by product review and we've finally done addressing their concerns. |
Hi @OmarIthawi, sure, our iOS dev @IvanStepanok will provide a review for this PR. |
|
Thanks a ton @volodymyr-chekyrta and @IvanStepanok!! Looking forward for your review :) cc: @RawanMatar89 |
|
Hi @RawanMatar89 you make a great job! I have only few clarifications.🙏 In case when I use default configuration, when |
| analytics.userSignInClicked() | ||
| isShowProgress = true | ||
| do { | ||
| let user = try await interactor.SSOlogin(jwtToken: "239i2oi3jrf2jflkj23lf2f") |
There was a problem hiding this comment.
hardcoded JWT token maybe by mistake?
| public var cookieSignature: String? { | ||
| get { | ||
| let defaults = UserDefaults.standard | ||
| return defaults.string(forKey: UserDefaultKeys.cookieSignature.rawValue) |
There was a problem hiding this comment.
Maybe it's better to use KeychainSwift instead of userDefaults for security reasons?
|
|
||
| public init() {} | ||
|
|
||
| public let samlLoginSuccess = URL(string: "https://blue.zeitlabs.com/auth/complete/tpa-saml")! |
|
|
||
| // MARK: - Singleton | ||
|
|
||
| public static let shared = SSOHelper() |
There was a problem hiding this comment.
please use Container in AppAssembly instead of using shared🙏
|
|
||
| // WKScriptMessageHandler | ||
| public func userContentController(_ userContentController: WKUserContentController, | ||
| didReceive message: WKScriptMessage) { |
There was a problem hiding this comment.
formatting:
// WKScriptMessageHandler
public func userContentController(
_ userContentController: WKUserContentController,
didReceive message: WKScriptMessage
) {}
|
|
||
| } | ||
|
|
||
| public func webView(_ webView: WKWebView, |
There was a problem hiding this comment.
formatting:
public func webView(
_ webView: WKWebView,
decidePolicyFor navigationAction: WKNavigationAction,
decisionHandler: @escaping (WKNavigationActionPolicy) -> Void
) {
| guard let _ = webView.url?.absoluteString else { | ||
| return | ||
| } | ||
|
|
There was a problem hiding this comment.
Please remove extra space
| } | ||
|
|
||
| } | ||
|
|
Thank you @IvanStepanok for your time and review, 🙏🏻 
if not, please provide more details. Thanks |
|
LGTM🎉 |
| @@ -1430,7 +1454,7 @@ | |||
| "@loader_path/Frameworks", | |||
| ); | |||
| MARKETING_VERSION = 1.0; | |||
| PRODUCT_BUNDLE_IDENTIFIER = org.openedx.Authorization; | |||
| PRODUCT_BUNDLE_IDENTIFIER = org.openedx.Authorization.nelc; | |||
There was a problem hiding this comment.
Please return old PRODUCT_BUNDLE_IDENTIFIER and DEVELOPMENT_TEAM
| @@ -1416,7 +1440,7 @@ | |||
| CODE_SIGN_STYLE = Automatic; | |||
| CURRENT_PROJECT_VERSION = 1; | |||
| DEFINES_MODULE = YES; | |||
| DEVELOPMENT_TEAM = L8PG7LC3Y3; | |||
| DEVELOPMENT_TEAM = WKRCK9V34F; | |||
| @@ -1395,7 +1419,7 @@ | |||
| "@loader_path/Frameworks", | |||
| ); | |||
| MARKETING_VERSION = 1.0; | |||
| PRODUCT_BUNDLE_IDENTIFIER = org.openedx.Authorization; | |||
| PRODUCT_BUNDLE_IDENTIFIER = org.openedx.Authorization.nelc; | |||
| @@ -1381,7 +1405,7 @@ | |||
| CODE_SIGN_STYLE = Automatic; | |||
| CURRENT_PROJECT_VERSION = 1; | |||
| DEFINES_MODULE = YES; | |||
| DEVELOPMENT_TEAM = L8PG7LC3Y3; | |||
| DEVELOPMENT_TEAM = WKRCK9V34F; | |||
| @@ -1239,7 +1263,7 @@ | |||
| "@loader_path/Frameworks", | |||
| ); | |||
| MARKETING_VERSION = 1.0; | |||
| PRODUCT_BUNDLE_IDENTIFIER = org.openedx.Authorization; | |||
| PRODUCT_BUNDLE_IDENTIFIER = org.openedx.Authorization.nelc; | |||
| @@ -1146,7 +1170,7 @@ | |||
| "@loader_path/Frameworks", | |||
| ); | |||
| MARKETING_VERSION = 1.0; | |||
| PRODUCT_BUNDLE_IDENTIFIER = org.openedx.Authorization; | |||
| PRODUCT_BUNDLE_IDENTIFIER = org.openedx.Authorization.nelc; | |||
| @@ -1132,7 +1156,7 @@ | |||
| CODE_SIGN_STYLE = Automatic; | |||
| CURRENT_PROJECT_VERSION = 1; | |||
| DEFINES_MODULE = YES; | |||
| DEVELOPMENT_TEAM = L8PG7LC3Y3; | |||
| DEVELOPMENT_TEAM = WKRCK9V34F; | |||
| @@ -1048,7 +1072,7 @@ | |||
| "@loader_path/Frameworks", | |||
| ); | |||
| MARKETING_VERSION = 1.0; | |||
| PRODUCT_BUNDLE_IDENTIFIER = org.openedx.Authorization; | |||
| PRODUCT_BUNDLE_IDENTIFIER = org.openedx.Authorization.nelc; | |||
| @@ -1034,7 +1058,7 @@ | |||
| CODE_SIGN_STYLE = Automatic; | |||
| CURRENT_PROJECT_VERSION = 1; | |||
| DEFINES_MODULE = YES; | |||
| DEVELOPMENT_TEAM = L8PG7LC3Y3; | |||
| DEVELOPMENT_TEAM = WKRCK9V34F; | |||
| @@ -955,7 +979,7 @@ | |||
| "@loader_path/Frameworks", | |||
| ); | |||
| MARKETING_VERSION = 1.0; | |||
| PRODUCT_BUNDLE_IDENTIFIER = org.openedx.Authorization; | |||
| PRODUCT_BUNDLE_IDENTIFIER = org.openedx.Authorization.nelc; | |||
There was a problem hiding this comment.
revert in all places plz🙏
| @@ -88,6 +88,21 @@ public class SignInViewModel: ObservableObject { | |||
| } | |||
| } | |||
|
|
|||
| @MainActor | |||
| func ssoLogin(title: String) async { | |||
|
|
|||
There was a problem hiding this comment.
Please remove extra space
| // WKScriptMessageHandler | ||
| public func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) { |
There was a problem hiding this comment.
Please align comment to function
|
|
||
| isShowProgress = true | ||
| for cookie in cookies { | ||
|
|
There was a problem hiding this comment.
please remove extra space
| case SSOBaseURL = "SSO_URL" | ||
| case SuccessfulSSOLoginURL = "SSO_URL_SUCCESSFUL_LOGIN" | ||
| case ssoButtonTitle = "SSO_BUTTON_TITLE" |
There was a problem hiding this comment.
Please change the first letters to lowercase
| case SAMLSSOLoginEnabled = "SAML_SSO_LOGIN_ENABLED" | ||
| case SAMLSSODefaultLoginButton = "SAML_SSO_DEFAULT_LOGIN_BUTTON" |
There was a problem hiding this comment.
Please change the first letters to lowercase
| if appStorage.accessToken == nil || | ||
| appStorage.refreshToken == nil { | ||
| appStorage.accessToken = jwtToken | ||
| appStorage.refreshToken = jwtToken |
There was a problem hiding this comment.
Unfortunately, I cannot test this code, but usually, accessToken differs from the refreshToken for security reasons.
Please check if this approach works and refresh the token.
There was a problem hiding this comment.
I agree, refreshToken isn't provided via the cookie so we should keep it null if possible.
OpenEdX/DI/ScreenAssembly.swift
Outdated
| container.register(SSOWebViewModel.self) { r in | ||
| SSOWebViewModel( | ||
| interactor: r.resolve(AuthInteractorProtocol.self)!, | ||
| router: r.resolve(AuthorizationRouter.self)!, | ||
| config: r.resolve(ConfigProtocol.self)!, | ||
| analytics: r.resolve(AuthorizationAnalytics.self)!, | ||
| ssoHelper: r.resolve(SSOHelper.self)! | ||
| ) | ||
| } |
There was a problem hiding this comment.
Please format ')'
default_config/dev/config.yaml
Outdated
| @@ -1,8 +1,19 @@ | |||
| API_HOST_URL: 'http://localhost:8000' | |||
| SSO_URL: 'http://localhost:8000' | |||
| SSO_URL_SUCCESSFUL_LOGIN: 'http://localhost:8000' | |||
There was a problem hiding this comment.
What do you think about renaming SSO_URL_SUCCESSFUL_LOGIN to a more general SSO_REDIRECT_URL?
There was a problem hiding this comment.
I think it means SSO_FINISHED_URL which is the URL we read the cookie from.
There was a problem hiding this comment.
✅
I used SSO_FINISHED_URL, please let me if you prefer SSO_REDIRECT_URL
default_config/dev/config.yaml
Outdated
| SSO_BUTTON_TITLE: { | ||
| ar: "الدخول عبر SSO", | ||
| en: "Sign in with SSO" | ||
| } |
There was a problem hiding this comment.
Please follow code style:
parent_key:
child_key1:
child_key2:
default_config/dev/config.yaml
Outdated
| UI_COMPONENTS: | ||
| COURSE_UNIT_PROGRESS_ENABLED: false | ||
| COURSE_NESTED_LIST_ENABLED: false | ||
| COURSE_NESTED_LIST_ENABLED: true | ||
| LOGIN_REGISTRATION_ENABLED: true | ||
| SAML_SSO_LOGIN_ENABLED: true | ||
| SAML_SSO_DEFAULT_LOGIN_BUTTON: false |
There was a problem hiding this comment.
Please do not change the default behavior of feature flags.
default_config/dev/config.yaml
Outdated
| UI_COMPONENTS: | ||
| COURSE_UNIT_PROGRESS_ENABLED: false | ||
| COURSE_NESTED_LIST_ENABLED: false | ||
| COURSE_NESTED_LIST_ENABLED: true |
There was a problem hiding this comment.
| COURSE_NESTED_LIST_ENABLED: true | |
| COURSE_NESTED_LIST_ENABLED: false |
That's what you mean @volodymyr-chekyrta, right?
|
|
||
| "SIGN_IN.SSO_HEADING" = "Start today to build your career with confidence"; | ||
| "SIGN_IN.SSO_SUPPORTING_TEXT" = "An integrated set of knowledge and empowerment programs to develop the components of the endowment sector and its workers"; | ||
| "SIGN_IN.SSO_LOG_IN_TITLE" = "Sign IN"; |
There was a problem hiding this comment.
To double-check, is it intentionally used as an uppercase in "Sign IN," or should it be "Sign In" or "Sign in"?
Thank you.
There was a problem hiding this comment.
No, it is not intentional. It should be ‘Sign in’ (with only the first letter capitalized).
Thank you for pointing that out!
|
@volodymyr-chekyrta @IvanStepanok and @RawanMatar89 thank you for keeping the pace on this pull request! I'm glad that we're getting this feature upstream!! |
|
@RawanMatar89, could you please check? I'm getting an error with the default config. |
|
Hi @volodymyr-chekyrta, I removed the comma from the files, but still couldn’t reproduce the error you’re experiencing. Could you please provide more details or steps to help me investigate further? |
Thank you, it works fine now. |
|
Could you please hide the SSO button from the default configuration? 
|
Describtion:
added new button in sign in view named "Sign in with SSO" to be use for opening single sign on web view
Screenshots:
TODO: