Forum Discussion
NimbostratusAPM + Kerberos
Hello DevCentral,
I have a question for you. I need to handle the Kerberos authentication (SSO) on a web service. My APM policy prompts a logon page for the un-authenticated users. Now I want to implement that if a user have a Kerberos token it will be able to logon using SSO and then access directly to the webservice( no logon page). Now I'm using a 401 response but How can I show the logon page if the user does not have the Kerberos token ?
Thanks in advance,
Best regards,
M.
2 Replies
- Kevin_Stewart
Employee
Technically speaking it'd be easy to do in an access policy in iRules, based on the presence or absence or an Authorization header in the client's request. The problem is that browsers don't generally work that way. If you send a 401 on initial access, and the client is unable to satisfy it, the browser will either re-prompt the user or just fail completely. One of the best approaches to handling this scenario, if your environment supports it, is to filter the clients based on source IP address. Anyone that can requests a Kerberos ticket for a web server is very likely on the same network as that KDC, while everyone else may not be. You could then use an iRule or APM's IP Subnet Match agent in the visual policy to direct different types of users down different VPE paths. One path for a logon page, and the other for client side Kerberos.
- Kevin_Stewart
So two things:
-
I'm not sure a user-agent header evaluation is going to be reliable. Can you guarantee that a) all Kerberos-capable clients have the same UA, and that external clients will never have that UA? Is your environment set up such that external users come in with different source addresses than internal users? That would be a more reliable option.
-
The issue is that the browser gets "fixated" on one authentication type. If you send it a 401 in a response, then it's going to try Kerberos, and then maybe NTLM, and then eventually either Basic or just fail. This all happens in the browser without any server side intervention. Almost all modern browsers behave this way, and there's nothing you can do on the server side to control this.
-
