Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform
What are the Web Form, HTTP and Portal providers for?
Short answer
HTTP and Web Form are for identity sources that do not speak LDAP, RADIUS, SAML or OpenID Connect. HTTP sends the information the user writes in the login form to the organization's own authentication service (a REST API or an internal web service) with an HTTP request; Web Form sends the same information to the login form of an existing application that has no API and only a login page. In both, whether the login is considered successful is determined from the response with Success Conditions. Portal, on the other hand, does not verify the identity; it takes it from the session opened on another AGS-enabled vService that runs in portal mode; the user logs in once on the portal and does not log in again in the applications connected to the portal.
How Does It Work?
- HTTP: The path, method, headers and body of the request are defined in the provider; the address, port and TLS settings are defined in an Authentication Server record with the HTTP or HTTPS protocol. The user information is placed in the request with variables such as
%AGS_USER_INPUT(username); the user information in the response is written to the session with automatic mapping. - Web Form: TR7 sends the user information to the form at the Login Form URL address according to the Login Form Fields rows. No server record is used; the request goes out through the route table in the Namespace field of the provider.
- Portal: The vService in portal mode is selected in the Portal Gateway field of the provider. The application vService runs in Portal Application mode, and the portal is in the Trusted Portals list. If the user has logged in on the portal, the identity is taken from the portal session.
Comparison
| HTTP | Web Form | Portal | |
|---|---|---|---|
| When | The organization has an authentication API | The application has only a login page | Access to multiple applications with a single login is wanted |
| Where the user information goes | To the HTTP service of the organization | To the login form of the application | Nowhere; the identity is taken from the portal session |
| How success is recognized | Success Conditions: Status code (default; the expected code is 200), Cookie, Redirect URL, JSONata | The same options; in the form, the expected status codes come filled in with 301 and 302 | The identity being taken from the portal session |
| Prerequisite | HTTP / HTTPS server record | Login form address and field names | An AGS-enabled vService in portal mode |
These Types in TR7
All three types are selected with Provider Type on the AGS → Authentication → Authentication Providers screen and added to the flow as an Authentication Provider step. Web Form and Portal have no automatic attribute mapping; the attributes to be written to the session are mapped with Custom User Attribute Mapping. Details of the portal setup: What is the Portal; how do users reach several applications with a single sign-in?
Common Misconceptions
- "The HTTP provider passes the identity to the Backend Service." The HTTP provider verifies only the login; passing the verified identity to the application is done with Backend SSO Configurations (What is Backend SSO; how does AGS pass the user's identity to the application?).
- "Web Form needs a server record." Web Form does not use a server record; the address is written in the Login Form URL field.
- "The Portal provider can select any vService." All AGS-enabled vServices appear in the Portal Gateway list, but the record is saved only with a vService that runs in portal mode; when another vService is selected, the record is rejected with an invalid option error when the Add button is clicked. Since the list opens with the first vService selected, the selection must be verified.
How it is done in the documentation
Related questions
