Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 1 subscriber
  • Views 5277 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Transparent Mode SSO cached credentials

lightxx
So, https://www.sophos.com/support/knowledgebase/120791.aspx states that 
However, in UTM F/W >= 9.111, the proxy will use the last successful cached authentication for the same user, when non-standard web requests (HTTPS) are made, or when a non-browser application makes a web request. This feature will prevent further authentication challenges from the proxy so long as there is an initial (successful) standard HTTP request which has been authenticated.


Thing is, today I came to the office and the first web request using an IOS device (an app, not a browser) was to a https site, and presto, no authentication popup but the request went through.

Soooo ... I always thought that the credentials were just cached for 300 seconds, which means that given this was my first request that day I expected it to be flat out denied given that there is no way to present the user an authentication popup in the app. What gives?


This thread was automatically locked due to age.
Parents
  • 0
    My memory is fuzzy on how the latest UTM works (I work on multiple products) but it may be working as intended.

    The limitations are:
    The UTM cannot perform transparent mode AD SSO in a variety of situations.
    - HTTPS
    - HTTP with a URL that has a ?parameter
    - FTP over HTTP
    - The user agent does not include Mozilla, suggesting it is a non-browser request (This is not a limitation, but something we put in to allow for things like Adobe Update running a 1am)

    I think what it does is:
    - If authentication is required
    AND 
    - there is a user in the cache
    AND
    - the cache entry is older than 5 minutes
    AND
    - this is an HTTPS (etc) request
    THEN
    - use the expired cache entry

    The credentials are cached forever (until overwritten).  If the system requires credentials and the cache less than 300 seconds old, just use the cache.  If the system required credentials and the the cache is greater than 300 seconds, ask for credentials if you can and use the cache if you cannot.

    The proof would be in the log line that indicates the user and the authentication method.  I suppose you could do something to prove it was a specific user by giving them a special policy that would uniquely identify them.
Reply
  • 0
    My memory is fuzzy on how the latest UTM works (I work on multiple products) but it may be working as intended.

    The limitations are:
    The UTM cannot perform transparent mode AD SSO in a variety of situations.
    - HTTPS
    - HTTP with a URL that has a ?parameter
    - FTP over HTTP
    - The user agent does not include Mozilla, suggesting it is a non-browser request (This is not a limitation, but something we put in to allow for things like Adobe Update running a 1am)

    I think what it does is:
    - If authentication is required
    AND 
    - there is a user in the cache
    AND
    - the cache entry is older than 5 minutes
    AND
    - this is an HTTPS (etc) request
    THEN
    - use the expired cache entry

    The credentials are cached forever (until overwritten).  If the system requires credentials and the cache less than 300 seconds old, just use the cache.  If the system required credentials and the the cache is greater than 300 seconds, ask for credentials if you can and use the cache if you cannot.

    The proof would be in the log line that indicates the user and the authentication method.  I suppose you could do something to prove it was a specific user by giving them a special policy that would uniquely identify them.
Children
No Data