Latest update: 7.0.2
- Preface
- About IG
- IG As an HTTP Gateway
- Processing Requests and Responses
- Development Mode and Production Mode
- Decorators
- Configuration Parameters Declared as Property Variables
- Changing the Configuration and Restarting IG
- Understanding IG APIs With API Descriptors
- Sessions
- Secrets
- Installation in Detail
- About Securing Connections
- Installing IG in Standalone Mode
- Installing IG in Apache Tomcat
- Installing IG in Jetty
- Installing IG in JBoss EAP
- Preparing the Network
- Changing the Default Location of the Configuration Folders
- Preparing For Load Balancing and Failover
- Configuring IG For HTTPS (Client-Side)
- Using JWT Sessions
- Setting Up AM
- Getting Login Credentials From Data Sources
- Getting Login Credentials From AM
- Single Sign-On and Cross-Domain Single Sign-On
- Enforcing Policy Decisions From AM
- Hardening Authorization With Advice From AM
- Protecting Against CSRF Attacks
- Acting As a SAML 2.0 Service Provider
- Acting As an OAuth 2.0 Resource Server
- Acting As an OpenID Connect Relying Party
- Transforming OpenID Connect ID Tokens Into SAML Assertions
- Supporting UMA Resource Servers
- Configuring Routers and Routes
- Proxying WebSocket Traffic
- Implementing Not-Enforced URIs for Authentication
- Configuration Templates
- Extending IG
- Throttling the Rate of Requests to Protected Applications
- SAML 2.0 and Multiple Applications
Implementing Not-Enforced URIs for Authentication
By default, IG routes protect resources (such as a websites or applications) from all requests on the route's condition path. Some parts of the resource, however, do not need to be protected. For example, it can be okay for unauthenticated requests to access the welcome page of a web site, or an image or favicon.
The following sections give examples of routes that do not enforce authentication for a specific request URL or URL pattern, but enforce authentication for other request URLs: