# Other Configuration

## Discovery Bypass {#discovery-bypass}


In some situations, your application may already know the upstream authentication provider that Proxy should use, and you want the user to bypass the discovery screen. 

To do so, we will construct a URL for the Proxy that contains the following information:

1. The application's Entity ID
2. Relay State (the path on the app side where a user should end up after authenticating)
3. The upstream authentication provider's Entity ID

Once these parameters have been [URL encoded](https://www.samltool.com/url.php), they will be [query parameters](https://developer.mozilla.org/en-US/docs/Web/URI/Reference/Query) for the `HTTP-Redirect` binding URL for the Proxy. 


### URL Construction {#url-construction}


Final construction will look like this:





**Constructed URL Example**

```ts
$bindingUrl?spentityid=$SPEntityID&RelayState=$RelayState&IDPList=$IdpEntityID
```





Sending a user to the below example will tell a Cirrus proxy to use Google as the upstream authentication provider and return the user to a Cirrus test application which will display some attributes.





**Live Constructed URL**

```ts
https://support.proxy.cirrusidentity.com/saml2/idp/SSOService.php?spentityid=https%3A%2F%2Fstandard.monitor.cirrusidentity.com&RelayState=%2Fmodule.php%2Fcore%2Fauthenticate.php%3Fas%3Dmonitor-standard&IDPList=https%3A%2F%2Fgoogle.cirrusidentity.com%2Fgateway
```






## Scope Checking {#scope-checking}


In a federation, each authentication provider has certain scopes that it can use when asserting user attributes to avoid name collisions. 

For example, if two authentication providers had a user called "John" they would need a way to distinguish which "John" is from which provider. Using scoping, the first provider can assert the identifier as **john@orgA.com** and the second as **john@orgB.com**, where orgA and orgB are the domain names for the organizations associated with each provider.



> [!TIP]
> All of these scope checking features are configurable upon request. Changing defaults requires a support ticket.




### Exact Scope Checking {#exact-scope-checking}


The Proxy will check that the scope asserted from an authentication provider matches the allowed scope for the authentication provider. If a provider asserts a scope that it is not allowed, Proxy will remove that assertion.

This is enabled by default for these attributes: 

- `urn:oid:1.3.6.1.4.1.5923.1.1.1.6` (eduPersonPrincipalName)
- `urn:oid:1.3.6.1.4.1.5923.1.1.1.9` (eduPersonScopedAffilitation)


### Ignore Scope Checking {#ignore-scope-checking}


If you intend to use an authentication provider that does not have a fixed scope, you may opt to disable scope checking for that provider. For example, Google provides email for many enterprises. If you use Google via the Cirrus Gateway as a provider **and** use email address for `eduPersonPrincipalName` then that provider may assert a scope for any business that uses Google for email.

In this example, you would likely want to disable scope checking for that provider, and continue checking other providers. 



> [!TIP]
> Because of this common issue, ignoring scope checking is enabled by default for Cirrus Gateway providers which provide email service for multiple domains.