I am working on implementing electronic signatures for a perspective page where users are required to sign for an action before it gets performed. I am currently working with the session event authentication challenge, which works perfectly - However I have a requirement that states that the user must know exactly what they are signing for as the are signing for it.
My current implementation opens an embedded Idp window which allows the authentication.
Does it need to be a single page? I would do it similar to how most ecommerce sites operate with one page for the shipping info then passes you to the next page for the CC info. In your case do the form with the action and comments and then have an agreement button that launches the IDP for the authentication.
Though one second thought I’m not sure how that would function to prompt the IDP with an already logged in user. That’s not something I’ve had to deal with before.
You cannot control the actual login page/form.
This is a fundamental confusion people have, and it's easy to understand why, but when you log in to the IdP (or use the authentication challenge feature to login via an embedded frame) you are leaving Perspective and going to another "context" entirely.
While the majority of the time, that other "context" is also owned by Ignition, we must adhere to open standards for identity provider login so that third party identity providers can work with Ignition. So we have a very specific set of possible information we can provide, and we get a very specific set of possible information in return. Doing anything "custom" over the top just in case both sides are actually Ignition (which is not something Perspective "knows") would just lead to confusion for those folks who are not using Ignition's internal IdP, or who go from something custom working inside of Ignition and then get a corporate mandate to switch to a global SSO provider.
The 'answer' is essentially what @Nol already suggested - provide the context before invoking the authentication challenge, and then optionally confirm it again after the authentication challenge has come back successfully. But you cannot control the actual login form, or present your own "faked" login form (in a secure way).
If you really, truly, absolutely must have a custom login form, you need to create your own identity provider outside of Ignition that adheres to the relevant open standards and connect Ignition to it.
