Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 1 subscriber
  • Views 1899 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

eDir SSO and basic authentication performance

boquinn
I have been testing a copy of ASL 6.203 with eDirectory SSO and have noticed a disturbing bit of behavior. I don't know if it is my configuration that is the issue, or a product problem.

When, on your client machine, you are logged into Novell, SSO works fine and everything is great. BUT, if you are not logged into Novell and simply use basic authentication to ASL via the browser, your web browsing slows to a crawl.

Looking at the authentication log, it appears that while you are authenticated and cached, each piece of the page that is downloaded kicks off another attempt at SSO, rather than using your already cached credentials. Once that fails, it notices that you were previously authenticated and lets the download proceed.

The VERY disturbing thing about this is that while it is doing this SSO lookup over and over, utlization on the Netware LDAP server you have the ASL box pointed to goes way up to 80-100% and stays there until you stop browsing. And that is only with one user in testing......

Anybody experience anything similar or have any configuration suggestions? It seems like a bug where the cache of authenticated IP addresses is not checked before attempting SSO, but I am willing to entertain the possibility that I have screwed something up.


This thread was automatically locked due to age.
Parents
  • 0
    Hi,
    if you are not logged in, ASL of course searches the whole LDAP Tree for you IP Adress (and does not find it, you are not logged in). After that normal Authentication is done.... Next request same thing! I think the search for the IP Number is done every request, because it always fails (you are not logged in) and therefore not cached. This is the reason for the slow surfin and the high utilization of the LDAP Server....

    cu SveN
Reply
  • 0
    Hi,
    if you are not logged in, ASL of course searches the whole LDAP Tree for you IP Adress (and does not find it, you are not logged in). After that normal Authentication is done.... Next request same thing! I think the search for the IP Number is done every request, because it always fails (you are not logged in) and therefore not cached. This is the reason for the slow surfin and the high utilization of the LDAP Server....

    cu SveN
Children
  • 0 in reply to SveN_01
    That was my impression of what was happening as well. I am not sure I like it, though. [;)] 

    I was testing to get an idea of what would happen for folks who might not be logged into Novell who wanted to surf the internet. I don't know how much of a problem that will be in the real-world, though. However, if a single user browsing via basic authentication can put that much of a "hurt" on the LDAP server, the current method doesn't seem acceptable. 

    It would seem to me that once an IP has been authenticated via any means (basic or eDir SSO,) they should be placed in the cache of authorized IPs. That would allow for seemless use of either authentication method.
  • 0 in reply to boquinn
    Hi,
    I totaly agree with you, maybe Astaro should think about this.
    If SSO Fails and normal Authentication is used that the normal Authentication is cached also....

    cu SveN
  • 0 in reply to SveN_01
    I opened a support request on this issue and Astaro confirmed the behavior that I was seeing as well as our thoughts on why it was happening. They have assigned it to development. The explanatory note I got was:

    When someone isn't logged into Netware and their SSO fails, we fallback
    to Basic Authentication, what is going to happen is our authentication
    system is going to cache the user's credentials for about 600 seconds if
    they are successful in their Basic Auth. This way we aren't always
    trying to do an SSO authentication for that user. After the 600 seconds
    expire, our system will try another SSO auth. If that doesn't work,
    we'll fallback to Basic, and cache them again for 600 seconds. For the
    end user this is not real difference, as the browser caches the Basic
    Authentication credentials, but it is much less work for eDirectory as
    not every requests tries an SSO. 


    There is no target date for this change, but I am pleased to know that it is "in the pipe." Thanks, Astaro!
  • 0 in reply to boquinn
    We bought Astaro because the reseller promised me that Astaro was working on this issue. As I noticed in this thread Astaro actually was working on it. So why is this behavior still occuring. Why isn't it fixed yet.