Username Cookie Identity Propagator
cookieName) cookiePath) If one single access cookie is used for all applications, the value "/" can be used. If different tickets are used for different applications, the applications path should be used.
Note that only one access cookie per cookie path and name can exist. Make sure that this cookie name does not clash with other cookie's names. For example, do not use session cookie names such as "JSESSIONID".
Make sure the configuration flag Interpret Cookie Domains is set in the Airlock Gateway (WAF) configuration. If not, the cookie path is ignored and cookies in the cookie store are sent to any back-end HTTP request of the same session. This also means that there may be only one cookie per cookie name!
It is best to consult the corresponding documentation of the Airlock Gateway to get more accurate information on cookie handling.
cookieDomain) Because of security restrictions in browsers (same origin policy) it is usually not possible to set a cookie for a different domain unless the right-most two domain parts (e.g. "ergon.ch") are equal to that of the application setting the cookie.
It is possible that there are further restrictions regarding this in browsers.
If you are using a HTTP reverse proxy that stores the cookie in its session store (and does not send it to the client), make sure to understand the proxies interpretation of the cookie domain and cookie path.
Make sure the configuration flag Interpret Cookie Domains is set in the Airlock Gateway (WAF) configuration. If not, the cookie domain is ignored and cookies in the cookie store are sent to any back-end HTTP request of the same session. The cookie path is also ignored meaning that there may be only one cookie per cookie name!
Airlock also supports the following cookie domain values (if the flag Interpret Cookie Domains is set):
- The value
.*results in cookies being sent to all back-end servers. This is especially useful if one authentication ticket is used for multiple back-ends. - The value
@<fully-qualified-host>results in the cookie being treated as if it were set by the host specified by "<fully-qualified-host>". If using this value, make sure the corresponding mapping also uses the fully qualified hostname.
Note that only one cookie per cookie path and name can exist. Make sure that this cookie name does not clash with other cookie's names. For example, do not use session cookie names such as "JSESSIONID".
setSecureFlag) If the cookie is marked as secure, the browser (and any HTTP proxy behaving like a browser) should send the cookie only over secure connections.
Caution: If you think that setting this flag makes your application more secure, it is in most cases way better to adequately secure the access cookie by encrypting it appropriately. Remember that this flag just "asks" the browser to not transmit the cookie over unencrypted connections.
urlEncodingScheme) Make sure that the component receiving the ticket uses the same URL encoding scheme.
Specify
NONE to disable URL-Encoding in case the target system cannot handle URL-Encoded cookies. Notice: This will only work if the username contains nothing but ASCII characters. Other characters like umlauts are never allowed unencoded in cookies and will result in an error. maxAge) - A positive value indicate that the cookie will expire after that many seconds have passed.
- A negative value means that the cookie is not stored persistently and will usually be deleted when the Web browser exits (however, browsers may keep it for longer).
- A value of 0 (zero) causes the cookie to be deleted by sending an expired cookie with the same name.
type: UsernameCookieIdentityPropagator
id: UsernameCookieIdentityPropagator-xxxxxx
displayName:
comment:
properties:
cookieDomain:
cookieName: username
cookiePath: /
maxAge: -1
setSecureFlag: false
urlEncodingScheme: UTF-8