feat: add single sign on feature using SAML

[RawanMatar89]

Describtion:

added new button in sign in view named "Sign in with SSO" to be use for opening single sign on web view

Screenshots:

Before	After
e.g. when tap on "Sign in with SSO"

TODO:

• Rebase and remove the RTL commit
• Fix unit tests
• Get a full review

[openedx-webhooks]

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 approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

• If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
  • This process (including the steps you'll need to take) is documented here.
• If it doesn't, simply proceed with the next step.

🔘 Provide context

To 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:

• Dependencies

  This PR must be merged before / after / at the same time as ...

• Blockers

  This PR is waiting for OEP-1234 to be accepted.

• Timeline information

  This PR must be merged by XX date because ...

• Partner information

  This is for a course on edx.org.

• Supporting documentation
• Relevant Open edX discussion forum threads

🔘 Get a green build

If 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 @openedx/openedx-mobile-maintainers. Tag them in a comment and let them know that your changes are ready for review.

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:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

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:

• The size and impact of the changes that it introduces
• The need for product review
• Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

[OmarIthawi]

@RawanMatar89 please rebase over openedx:develop, resolve conflicts and fix the failing tests like:

[ProfileTests] Write Auxiliary File ProfileTests_vers.c
Error: type 'AuthInteractorProtocolMock' does not conform to protocol 'AuthInteractorProtocol'
open class AuthInteractorProtocolMock: AuthInteractorProtocol, Mock {
           ^
Error: type 'BaseRouterMock' does not conform to protocol 'BaseRouter'
open class BaseRouterMock: BaseRouter, Mock {
           ^
Error: type 'ProfileRouterMock' does not conform to protocol 'BaseRouter'
open class ProfileRouterMock: ProfileRouter, Mock {
           ^
[ProfileTests] Compiling EditProfileViewModelTests.swift

Testing failed:
	Type 'AuthInteractorProtocolMock' does not conform to protocol 'AuthInteractorProtocol'
	Type 'BaseRouterMock' does not conform to protocol 'BaseRouter'
	Type 'ProfileRouterMock' does not conform to protocol 'BaseRouter'
	Command SwiftCompile failed with a nonzero exit code
	Testing cancelled because the build failed.

** TEST FAILED **


The following build commands failed:
	SwiftEmitModule normal arm64 Emitting\ module\ for\ ProfileTests (in target 'ProfileTests' from project 'Profile')
	SwiftCompile normal arm64 Compiling\ ProfileMock.generated.swift,\ DeleteAccountViewModelTests.swift /Users/runner/work/openedx-app-ios/openedx-app-ios/Profile/ProfileTests/ProfileMock.generated.swift /Users/runner/work/openedx-app-ios/openedx-app-ios/Profile/ProfileTests/Presentation/DeleteAccount/DeleteAccountViewModelTests.swift (in target 'ProfileTests' from project 'Profile')
(2 failures)

[OmarIthawi]

@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.

[RawanMatar89]

@volodymyr-chekyrta we have finished all the changes and test cases, kindly review this feature that we'd like to merge it

[OmarIthawi]

@mphilbrick211 I've removed the FC label as this is not a funded contribution.

[OmarIthawi]

@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.

[marcotuts]

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.)

[OmarIthawi]

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:

• Show SAML button
• What to put as a SAML button label
• The URL backend of the SAML button

Other configurable items can be supported such as jwt cookie name and others.

[OmarIthawi]

@RawanMatar89 please check Marco's comment and let us know.

[mphilbrick211]

@RawanMatar89 please check Marco's comment and let us know.

Friendly ping on this, @RawanMatar89!

[OmarIthawi]

@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

[marcotuts]

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.

[OmarIthawi]

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:

• Apps with exclusively SAML SSO login: Those will feature a single Login button that shows up a WebView similar to Rawan demo.
• Apps with both main username/password standard login and a secondary SSO button.
• Apps with only standard username/password login.

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.

[OmarIthawi]

@RawanMatar89 @marcotuts and @sdaitzman thanks for the discussion the other day on the product development.

I'm writing the notes from the meeting:

• The SAML SSO button should be hidden by default. The SAML SSO button should show up only if configured in YAML.
• Configuration setting to hide the regular login form.
• The SSO button design should appear as a secondary button in term of size and color by default. Can be configured as default button via the yaml file.
• The SSO button text should be configurable, and multi-lingual.

We discussed other good-to-have features but won't be blocking this PR:

• There can more than one SSO buttons (not a blocker at the moment)
• Embed WebView (not a blocker)
• The WebView SAML SSO button can be a plugin, instead of a hardcoded feature in the app (not a blocker at the moment)

Depending on the configuration we should support the following variations (Figma file):

Native-only	Native and SSO	SSO-only
Default view	If SSO is enabled	If SSO is enabled and the native login form disabled