If I put AGS in front of my application, does the application need code changes?

Short answer

No. The login page, authentication, MFA and session management are carried out by AGS on TR7; a request without a session never reaches the application. If the application needs to recognize the user, the identity is added in a way the application already supports: with the Injections in the Backend SSO Configurations profile, as a header, Basic Auth, a Bearer Token or a cookie. If the application has a path that starts with /ags-portal, only AGS Root Path is changed, because the requests on this path go to AGS.

How Does It Work?

1. A user without a session is taken into the login flow; the application does not see these requests.
2. Requests that come with a session are forwarded to the Backend Service. AGS's own cookies are removed from the request; the application's cookies remain as they are.
3. If a Backend SSO profile is bound to the vService, the injections are added to the request whose session has been verified. A header or cookie with the same name that comes from the client is deleted first; the identity information that reaches the application comes only from AGS.

The values are populated from the session with AGS variables such as %AGS_USERNAME, %AGS_EMAIL, %AGS_GROUPS and %AGS_USER_ATTR(department).

In TR7, Depending on the Application

Application	What is done on the AGS side
Has no authentication and does not need to recognize the user either	AGS is enabled and the flow is set up, nothing more; Backend SSO is not required.
Reads the user from an HTTP header	Header injection (Header Name, Header Value)
Expects HTTP Basic Auth	Basic Auth injection (Username Source, Password Source)
Expects a Bearer Token	Bearer Token injection
Reads the identity from a cookie	Cookie injection (Cookie Name, Cookie Value)
Has only its own login form	With the Web Form provider, the identity is verified in the application's own form

The profile is bound to the vService in the Backend SSO Config field of the General Settings window on the Flowchart tab. What happens when the application's own session drops or the user logs out of the application is determined by Backend Session Lost Strategy and Backend Logout Condition in the same profile.

Common Misconceptions

• "If the application does not support OAuth2 or SAML 2.0, AGS cannot use these providers." It is AGS that talks to the external identity provider (IdP); the application either reads only the identity added with Backend SSO or does not read it at all.
• "An identity passed in a header can be spoofed by the client." When the injected header and cookie names come from the client, they are deleted first; the value that reaches the application is the value AGS writes.
• "AGS Root Path is caught only on an exact match." The match is made by text prefix; if the application has a path that starts with the same prefix, AGS Root Path is changed (What do AGS Activation Condition and AGS Root Path determine?).

How it is done in the documentation

• AGS - AAM · Identity Propagation to the Backend Service
• Backend SSO Configurations · What Are Backend SSO Configurations?
• Backend SSO Configurations · Injections
• Flowchart · AGS Root Path

Related questions

• What is Backend SSO; how does AGS pass the user's identity to the application?
• Where does authentication happen: in TR7, in the application or at the identity provider?
• What are the Web Form, HTTP and Portal providers for?