Discussion on:
View:
Show:
Is your organization using both Oracle 10g and .NET? How do they work together? Do you recommend others follow your example?
We don't have dot net asp, so to try this out instead of Request.Headers.Item("Osso-User-Dn"), you need to say
userdn = Request.ServerVariables("HTTP_Osso-User-Dn")
Hope this saves someone else a lot of googling.
Steve
userdn = Request.ServerVariables("HTTP_Osso-User-Dn")
Hope this saves someone else a lot of googling.
Steve
We have done a proof of concept, and I was concerned that header crafting was an obvious exploit. What we have done to prevent this is use IP filtering on the IIS application, to only allow requests from the proxy / proxies. This way, you know all requests have been protected by SSO. The only way a request without the header will then arive at the application, is if there is a mis-configuration at the proxy / mod-osso level, and access can be immediately denied.
"If the application detects that the Osso-User-Dn header is not set..."
This enables but does not enforce security, making it technically a business edit, not system security. If every piece of app code has to check to see if someone is logged on, even the business edit is only as good as the poorest app and the least imaginative hacker (including inside hackers). The solution is to configure the authentiation to automatically pass through via system configured components, eg a trusted kerberos ticket, not app code. Then security is enforced by NET regardless of which interface or back door is used.
This enables but does not enforce security, making it technically a business edit, not system security. If every piece of app code has to check to see if someone is logged on, even the business edit is only as good as the poorest app and the least imaginative hacker (including inside hackers). The solution is to configure the authentiation to automatically pass through via system configured components, eg a trusted kerberos ticket, not app code. Then security is enforced by NET regardless of which interface or back door is used.
Any protected web application needs to check who is logged in in order to provide role based access. Plus, any authentication mechanism, even using a trusted kerberos ticket, requires session validation in one or another component of the application. Looking at a big picture, I am not sure the above concern is valid at all: Oracle SSO provides a strong authentication mechanism.
Suppose I'm logged into the app as Joe_Mailroom which is being sent in the headers. Then I hack my own header on the client to say Sam_SeniorManager. Wouldn't that be pretty easy? We are currently doing something vaugely like this to bring an old oracle webserver (pre-mod osso) under sso. But we add a portal session id to the incomming request and our non-sso app does a sql callback to get the username. All to avoid someone easily hacking a request parm.
Malik, Did you actual do this? and if so, HOW???
How did you actual do it? AND HOW DID YOU GET IT TO WORK?
HOW DID YOU GET THE PROXY TO REFERANCE THE CORRECT WEBResources.AXD file?????
Thanks,
How did you actual do it? AND HOW DID YOU GET IT TO WORK?
HOW DID YOU GET THE PROXY TO REFERANCE THE CORRECT WEBResources.AXD file?????
Thanks,
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
