The answer is quite simple to give.
In fact, the login page is easy to implement. What happens is, upon successful login, ISAM will return a "Successful login" page that is stored in ISAM, and the customer wants his own pages, including error pages, and so on.
The solution you provide, only allows the login page to be user-defined. All remaining pages, will be served by ISAM.
I know this solution is supported using the local response redirect.
But the configuration of this feature "local response redirect" seems to only support a "normal" authentication flow, I cannot find a way to configure the "consent" page.
"The OAuth 2.0 - Consent to Authorize" page has its own css, logo, and so on, and the customer was to replace with its own React based page.
But you reply also raises another question. According to you, "The OP is usually responsible for rendering the login page".
The OP is implemented by serving a set of endpoints which are configured in the first steps of the OIDC configuration.
After this, we have to create a junction (defaults to /mga). Who is responsible for sending the login page? The page configuration options (including login page) are defined in the Reverse Proxy. So, all junctions defined in the reverse proxy will get the same login pages.
So, in case of OIDC, when anyone tries to access the endpoint (e.g. authorize), it will be the reverse proxy that prevents the user to access the endpoint, by presenting the login page.
From your statement, you seem to indicate that this is not what will happen. In fact, when you say that the OP is responsible for rendering the page, you are implying that the reverse proxy or junction will ask the OP, to render the login page!
If this is true, then if I configure the reverse proxy to use local response direct will not work!
Finally, when you state that "I personally don't believe that you will be able to get your existing scenario to work without a lot of additional effort - and even then I don't know if even could be made to work.", then how can I do this? What are the steps required to achieve this goal?
------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994
------------------------------
Original Message:
Sent: Thu October 15, 2020 03:52 PM
From: Scott Exton
Subject: Using external reverse proxy pages
Joao,
You are describing an unusual scenario. The OP is usually responsible for rendering the login page if it is handling the authentication. In your case it sounds like you want the application to render the login page, which in turn POSTs the authentication data to the OP. What is preventing you from having the authentication page presented by the OP, even if this is configured as a local-response-redirect back to the login page which is hosted by the application? This is the usual way of configuring things.
I personally don't believe that you will be able to get your existing scenario to work without a lot of additional effort - and even then I don't know if even could be made to work.
Scott A. ExtonSenior Software Engineer
Chief Programmer - IBM Security Verify AccessIBM Master Inventor
|
Phone: 61-7-5552-4008
E-mail: scotte@au1.ibm.com |
1 Corporate Court
Bundall, QLD 4217
Australia
|
Original Message:
Sent: 10/15/2020 4:50:00 AM
From: Joao Goncalves
Subject: RE: Using external reverse proxy pages
Thanks for the answer, but I was not clear enough in my questions. I am using OIDC. In this scenario, ISAM is being used as the OProvider, and an external application is the Relying Partner (RP).
A user, using the Browser tries to access the RP which presents him with a login page, which is hosted in an Application Server (AP).
After a more careful reading of the documentation, I understand that the AP must implement a "Response Handler" that will return a requested page. This Response Handler can be easily be accessed using a ISAM junction, in fact, you cannot redirect the user to a different server, it must be served by ISAM (please confirm this statement).
The response handler, will get all parameters required to compose the page to be sent to the user, which includes the operation (TAM_OP param) and the original request (URI param). The TAM_OP parameter will inform the Response Handler what page is needed.
But I do not see that I can service the "Consent page" required by OIDC! Consent Page is defined in the "Template" file on AAC. How can I redirect such page to Response Handler?
------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994
Original Message:
Sent: Wed October 14, 2020 09:09 PM
From: Scott Exton
Subject: Using external reverse proxy pages
Joao,
In answer to your questions:
Does this means that once ISAM receives the request:
- Send a redirect to the customer with a URL he can use to access the Application Server where the needed page is served?
- Send a redirect to the customer with a junction URL that can be used for ISAM to get the needed page?
Ans: Once ISAM receives the request a redirect is sent to the configured URL. This URL can live anywhere (doesn't need to be a junction). The hosting application is responsible for returning the appropriate page back to the client.
After getting a login page, the customer provides the username and password. How does the Application Server Page know the URL to use when the customer clicks on a Submit Button?
Ans: The application server just needs to have the URL hard-coded: 'https://<server>/pkmslogin.form'
I also see in the documentation that ISAM is using redirection (302 redirects). Again I'm confused how the process flow is executed.
Ans: I don't understand where the confusion lies.
Scott A. ExtonSenior Software Engineer
Chief Programmer - IBM Security Verify AccessIBM Master Inventor
|
Phone: 61-7-5552-4008
E-mail: scotte@au1.ibm.com |
1 Corporate Court
Bundall, QLD 4217
Australia
|
Original Message:
Sent: 10/14/2020 7:15:00 PM
From: Joao Goncalves
Subject: RE: Using external reverse proxy pages
Thanks for the information. I already read briefly the documentation, but I have questions regarding how it supported.
According to the documentation:
- WebSEAL receives the client request.
- WebSEAL determines that it must return a response that would normally be handled by returning a static HTML page, such as a login or error page.
- WebSEAL builds a Location header in the response that contains the URI of a custom response handling application located on a separate server.
- WebSEAL includes, as an attribute in the query string of the Location header, the type of operation required (such as "login required", "expired password", or "error") and an optional set of configurable WebSEAL macros and their values.
- WebSEAL redirects the client to this custom response handling application.
- The custom response handling application is responsible for presenting an appropriate response or set of responses to the client.
Does this means that once ISAM receives the request:
- Send a redirect to the customer with a URL he can use to access the Application Server where the needed page is served?
- Send a redirect to the customer with a junction URL that can be used for ISAM to get the needed page?
In any case, after this initial step, I am confused how the process continues.
- After getting a login page, the customer provides the username and password. How does the Application Server Page know the URL to use when the customer clicks on a Submit Button?
I also see in the documentation that ISAM is using redirection (302 redirects). Again I'm confused how the process flow is executed.
------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994
Original Message:
Sent: Wed October 14, 2020 04:52 PM
From: Scott Exton
Subject: Using external reverse proxy pages
Joao,
Thanks.
Scott A. ExtonSenior Software Engineer
Chief Programmer - IBM Security Verify AccessIBM Master Inventor
|
Phone: 61-7-5552-4008
E-mail: scotte@au1.ibm.com |
1 Corporate Court
Bundall, QLD 4217
Australia
|
Original Message:
Sent: 10/14/2020 8:05:00 AM
From: Joao Goncalves
Subject: Using external reverse proxy pages
When using a reverse proxy, we can customize the pages available, including login.html, login_success.html, and so on.
I have a customer that want to use his own pages, which are written using React, or other technologies/frameworks.
He is proposing having all pages, including login page, serviced on application server.
For example for the login process it would work this way:
- The user is directed to Customer Login Page
- The user inserts his credentials
- The Customer Login Page sends the credentials to ISAM for him to be authenticated, and the SSO flow to continue (using OIDC)
According the to documentation, (https://www.ibm.com/support/knowledgecenter/en/SSPREK_9.0.7/com.ibm.isam.doc/wrp_config/task/tsk_submt_form_data_ws.html), this can be easily done.
But how about the other pages (logout.html, and consent page, and more)?
Is this possible?
For example, after sending a pkmslogin.form with username and password, and upon successful login, ISAM send the login_success.html, but I would to return and external page to the user instead!
What must be done to make this possible.
What are the key problems on this approach? For, example, if he fails to login, how do I redirect him to the login page again, or to the Customer failed login page!
If the OIDC authorize flow or any other flow, fails, how do I send the Customer error pages?
------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994
------------------------------