[3.x] Native Android and iOS implementation integration support

[illambo]

Please check these requirements

• [X] This feature helps everyone using this package
• [X] It's feasible and maintainable
• [X] It's non breaking
• [X] I issued a PR with the implementation (#84)

Description

Studying the integration of the library on Android and iOS we found that although via WebView (both platform) or Android CustomTabs / iOS SFSafariViewController there are no difficulties, it is necessary to carry out a small server side integration to allow the native implementation of the solution on Android and iOS.

The evaluation of this analysis was done with a small poc (actors: android / ios / web / server), in essence, everything translates (in addition to the various configurations of the case for both environments which are not the responsibility of this library) in:

• allowing an array of valid strings as origin (necessary for Android, see Sign in your user with Credential Manager -> Verify origin from client data JSON)
• in our opinion, add the integration of the Relying Party (rpId) in the option assertion response (this would be useful for both Android and iOS) to allow suggestion of appropriate keys on the device side.

On the implementation side, the areas of impact that I find are:

• configuration / env: possibility to configure an array of valid "origins" (strings).
• SharedPipes/CheckOriginSecure adaptation implementation for allow valid origins integration
• SharedPipes/CheckRelyingPartyIdContained adaptation implementation for allow valid sources integration
• Create pipe for attach rpId and add to Assertion\Creator\AssertionCreator pipeline

I looked at a previous "draft" of closed pr #61 which went in that direction, although in my opinion it can be simplified with a simple in_array (match string) to be able to also be used for other possible non-Android scenarios. For example, for Android I would value with the already calculated android:apk-key-hash (e.g. android:apk-key-hash:hlbf0LpDSuQ3UpvvmFAMc1OhrD96549OYYOkGJKxJVs) instead of calculating the relevant fingerprint (see detail on the composition), in order to make everything simpler (avoid recalculations at each request) and not differentiate per os (possibly commands could be provided for os as helpers to generate the appropriate strings).

Although at the current state of the branches it seems to me that this feat is also compatible on 2.x, perhaps it is better to keep 3.x as the basis (I don't seem to see any conflicts but I don't understand the tests part).

Let me know what you think, thanks.

[DarkGhostHunter]

I think it would be great for 3.x. The areas of impact doesn't seem like too "impactful", since basically the pipe need to account for multiple configurable origin strings and rpId, am I correct?

[illambo]

Right, 2 pipes already present and maybe one to add for add rpId.

[illambo]

Thanks for the integration and release!

[DarkGhostHunter]

No prob. Note that I removed a pipe and al RP checks are done in one single pipe.