2

I have an enterprise web application that will integrate with a single sign on (SSO) service via Integrated Windows Authentication (IWA). The SSO service is providing authentication only (not authorization). This web application will handle authorization through a custom authorization module. We are running IIS 6 on Windows 2003.

Once a user authenticates via IWA, IIS by default will execute the web page under the context of the user logged in. So typically we have an Active Directory security group object that we assign Read/Execute permissions over the website directory - any user object that is a member of this designated security group can see/execute the web page. Any AD user that successfully authenticates against AD, but does not belong to this security group gets a HTTP 401 (access denied).

For this project though we don't want to have the maintenance of added/removing AD User Objects for the designated security group. Our thought is instead to assign the Authenticated_Users group read/execute permissions over the website directory files. This way if you can authenticate you will by default be able to see/execute the page request.

Is this safe? From my team's perspective it is safe as long as the authorization module in this web application does it's job.

Is anyone else doing this or do you have another approach to managing authorization when using Integrated Windows Authentication on IIS?

Steve Flook
  • 195
  • 5

1 Answers1

1

So long as your authorization module works as advertised you should not have any problems. It is an oft overlooked separation (authentication and authorization). You just take the onus of authorization upon yourself (within the app), but obviously that's what you want! Like you say, all the Windows security group will be doing is providing a mechanism for authentication which has nothing to do with actual permissions within your app.

squillman
  • 37,618
  • 10
  • 90
  • 145