"Shibbolising" ASP .Net application(s)

[Cantor, Scott]

On 7/26/13 5:31 AM, "Gilles Badouet" <badouetg at uni.coventry.ac.uk> wrote:

>>That generally means you will have a lot of trouble ripping out or
>>routing
>>around existing behavior.
>
>Why? I note that I  don't have necessarily to associate the Shibboleth
>base authentication to the existing authentication system. I have nothing
>to do with the existing authentication box. I got the application library
>and what I have to do is to experiment the Shibboleth authentication
>system within another box and indepently on the existing authentication.

Based on a simple interpretation of your description, the application may
insist on asking for a password and then checking a database. It may be
unable and unwilling to stop doing that, and rely on an identity provided
by a web server. And there is no scenario in which you can deploy
Shibboleth on some other server and make it somehow protect an application
somewhere else. It does not work that way. It runs in a web server and
will supply identity via headers on that server to resources that are
hosted there, and that's it.

Making that work for an application that is a black box or that can't be
modified can be hard or impossible, and in any case requires a lot of
experience and certainly deep knowledge of the application to start with.

>(https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPEnableApplic
>ation) which files and which elements to configure.I just know that I
>have to place the application in "secure" folder.

You can protect any resource you like, but putting an application into a
folder will do nothing if it's not programmed to rely on the web server or
headers for authentication.

>I also read that 'Request Headers' is the only integration mechanism
>supported by IIS/ ASP .Net applications and don't understand how  and
>where to apply it.

If you can't modify the application or use an integration API that it
supports, you can't apply it anywhere.

-- Scott