Impersonation and integrated security (+sql server reporting servi

[Phil Aldis]

Hi,

I'm having a little difficulty getting my head round windows integrated
security/impersonation and I'd appreciate a little help with the problem I'm
trying to solve (or an indication that what I'm trying to do is too hard to
be worth it!)

To give you the background: I'm developing a web portal application which
has fairly limited number of users. We're using SQL Server reporting
services. A number of the reports need to be bound to groups of users; also,
some of the reports need to know the logged-in user to use directly in the
SQL queries. This can, of course, all be done using Windows Integrated
Authentication. Also, another piece of info, I can't justify the cost of the
Enterprise version of SQL Server and so cannot use a reporting services
custom security extension (eg Form based authentication). Also, I'm serving
up my reports using the reportviewer custom control, which loads reports into
an IFrame, so effectively creates its own http requests.

I have no problems creating accounts on the server for every user. What I
don't like, however, is the integrated security popup box. It's quite ugly
and from a user experience point of view really doesn't fit in with their
expectations of a web application, where they would expect a more forms based
view. I thought that I might be able to do something in the background
whereby they could login through a form and I could manaully do the logging
in, and from then on (until timeout) this user would be regarded by the
webapp and report server as the credentials supplied.

Okay, so I used the demo in msdn:
ms-help://MS.MSDNQTR.2004JUL.1033/cpref/html/frlrfSystemSecurityPrincipalWindowsIdentityClassIm personateTopic1.htm

and webapp'ed it. This works and I was hoping that if I didn't undo the
impersonation at the end, that all future http requests from this client
would be regarded as the impersonated user, which would obviously enable
someone to login and then when they view reports they would be that user. I
kinda knew that wasn't going to work and it feels like I might still be able
to do this by doing something with the security token.

Is what I'm trying to do mad? Am I going to have to implement my own
HttpHandler and impersonate the user I think someone is, at each request? It
would be great if there are any tutorials out there. Obviously if it's too
difficult, or will introduce huge security weaknesses in the system then it's
just not worth it. As I said, all I'm trying to do here is remove the popup
login box!

Thanks in advance for your help,

Phil Aldis

[Ken Schaefer]

Internet Explorer can be configured to automatically send the user's
credentials to the website if the site is in the local Intranet zone...then
you wouldn't see the pop-up login dialogue box (unless the currently logged
in user does not have sufficient privileges)

Would that help?

Cheers
Ken

"Phil Aldis" <Phil [email]Aldis@discussions.microsoft.com[/email]> wrote in message
news:1A0B3E9C-B133-4AAF-B29D-7E85FBE3187D@microsoft.com...

> Hi,
>
> I'm having a little difficulty getting my head round windows integrated
> security/impersonation and I'd appreciate a little help with the problem
> I'm
> trying to solve (or an indication that what I'm trying to do is too hard
> to
> be worth it!)
>
> To give you the background: I'm developing a web portal application which
> has fairly limited number of users. We're using SQL Server reporting
> services. A number of the reports need to be bound to groups of users;
> also,
> some of the reports need to know the logged-in user to use directly in the
> SQL queries. This can, of course, all be done using Windows Integrated
> Authentication. Also, another piece of info, I can't justify the cost of
> the
> Enterprise version of SQL Server and so cannot use a reporting services
> custom security extension (eg Form based authentication). Also, I'm
> serving
> up my reports using the reportviewer custom control, which loads reports
> into
> an IFrame, so effectively creates its own http requests.
>
> I have no problems creating accounts on the server for every user. What I
> don't like, however, is the integrated security popup box. It's quite ugly
> and from a user experience point of view really doesn't fit in with their
> expectations of a web application, where they would expect a more forms
> based
> view. I thought that I might be able to do something in the background
> whereby they could login through a form and I could manaully do the
> logging
> in, and from then on (until timeout) this user would be regarded by the
> webapp and report server as the credentials supplied.
>
> Okay, so I used the demo in msdn:
> ms-help://MS.MSDNQTR.2004JUL.1033/cpref/html/frlrfSystemSecurityPrincipalWindowsIdentityClassIm personateTopic1.htm
>
> and webapp'ed it. This works and I was hoping that if I didn't undo the
> impersonation at the end, that all future http requests from this client
> would be regarded as the impersonated user, which would obviously enable
> someone to login and then when they view reports they would be that user.
> I
> kinda knew that wasn't going to work and it feels like I might still be
> able
> to do this by doing something with the security token.
>
> Is what I'm trying to do mad? Am I going to have to implement my own
> HttpHandler and impersonate the user I think someone is, at each request?
> It
> would be great if there are any tutorials out there. Obviously if it's too
> difficult, or will introduce huge security weaknesses in the system then
> it's
> just not worth it. As I said, all I'm trying to do here is remove the
> popup
> login box!
>
> Thanks in advance for your help,
>
> Phil Aldis
>

[Phil Aldis]

Thanks for your response Ken.

The problem is that people are coming through the internet. Also, the IT
skill level of some of the people using the site is fairly low and I'm
slightly concerned that the popup is going to be fairly confusing. Also
having to fill in the domain is a bit confusing. As I said, it's really not
100% crucial and if it were, it's looking like the only way I can do it, is
to buy as Enterprise license and implement my own security extension for
reporting services that gives me lots more freedom.

One thing that doesn concern me: am I right in thinking that if I'm using
windows security, I'm preventing any non-IE browsers from using the site? Is
there any way round this?

Thanks,

Phil

"Ken Schaefer" wrote:

> Internet Explorer can be configured to automatically send the user's
> credentials to the website if the site is in the local Intranet zone...then
> you wouldn't see the pop-up login dialogue box (unless the currently logged
> in user does not have sufficient privileges)
>
> Would that help?
>
> Cheers
> Ken
>
> "Phil Aldis" <Phil [email]Aldis@discussions.microsoft.com[/email]> wrote in message
> news:1A0B3E9C-B133-4AAF-B29D-7E85FBE3187D@microsoft.com...

> > Hi,
> >
> > I'm having a little difficulty getting my head round windows integrated
> > security/impersonation and I'd appreciate a little help with the problem
> > I'm
> > trying to solve (or an indication that what I'm trying to do is too hard
> > to
> > be worth it!)
> >
> > To give you the background: I'm developing a web portal application which
> > has fairly limited number of users. We're using SQL Server reporting
> > services. A number of the reports need to be bound to groups of users;
> > also,
> > some of the reports need to know the logged-in user to use directly in the
> > SQL queries. This can, of course, all be done using Windows Integrated
> > Authentication. Also, another piece of info, I can't justify the cost of
> > the
> > Enterprise version of SQL Server and so cannot use a reporting services
> > custom security extension (eg Form based authentication). Also, I'm
> > serving
> > up my reports using the reportviewer custom control, which loads reports
> > into
> > an IFrame, so effectively creates its own http requests.
> >
> > I have no problems creating accounts on the server for every user. What I
> > don't like, however, is the integrated security popup box. It's quite ugly
> > and from a user experience point of view really doesn't fit in with their
> > expectations of a web application, where they would expect a more forms
> > based
> > view. I thought that I might be able to do something in the background
> > whereby they could login through a form and I could manaully do the
> > logging
> > in, and from then on (until timeout) this user would be regarded by the
> > webapp and report server as the credentials supplied.
> >
> > Okay, so I used the demo in msdn:
> > ms-help://MS.MSDNQTR.2004JUL.1033/cpref/html/frlrfSystemSecurityPrincipalWindowsIdentityClassIm personateTopic1.htm
> >
> > and webapp'ed it. This works and I was hoping that if I didn't undo the
> > impersonation at the end, that all future http requests from this client
> > would be regarded as the impersonated user, which would obviously enable
> > someone to login and then when they view reports they would be that user.
> > I
> > kinda knew that wasn't going to work and it feels like I might still be
> > able
> > to do this by doing something with the security token.
> >
> > Is what I'm trying to do mad? Am I going to have to implement my own
> > HttpHandler and impersonate the user I think someone is, at each request?
> > It
> > would be great if there are any tutorials out there. Obviously if it's too
> > difficult, or will introduce huge security weaknesses in the system then
> > it's
> > just not worth it. As I said, all I'm trying to do here is remove the
> > popup
> > login box!
> >
> > Thanks in advance for your help,
> >
> > Phil Aldis
> >

>
>
>

[Raterus]

You are correct, integrated windows authentication is only supported when the client uses IE. Though if you still needed to use windows accounts, basic authentication is supported by almost all browsers, and digest authentication is supported by some of them.

--Michael

"Phil Aldis" <PhilAldis@discussions.microsoft.com> wrote in message news:7C43F6DF-1912-4EFF-AB9B-7FD531140C48@microsoft.com...

> Thanks for your response Ken.
>
> The problem is that people are coming through the internet. Also, the IT
> skill level of some of the people using the site is fairly low and I'm
> slightly concerned that the popup is going to be fairly confusing. Also
> having to fill in the domain is a bit confusing. As I said, it's really not
> 100% crucial and if it were, it's looking like the only way I can do it, is
> to buy as Enterprise license and implement my own security extension for
> reporting services that gives me lots more freedom.
>
> One thing that doesn concern me: am I right in thinking that if I'm using
> windows security, I'm preventing any non-IE browsers from using the site? Is
> there any way round this?
>
> Thanks,
>
> Phil
>
> "Ken Schaefer" wrote:
>

> > Internet Explorer can be configured to automatically send the user's
> > credentials to the website if the site is in the local Intranet zone...then
> > you wouldn't see the pop-up login dialogue box (unless the currently logged
> > in user does not have sufficient privileges)
> >
> > Would that help?
> >
> > Cheers
> > Ken
> >
> > "Phil Aldis" <Phil [email]Aldis@discussions.microsoft.com[/email]> wrote in message
> > news:1A0B3E9C-B133-4AAF-B29D-7E85FBE3187D@microsoft.com...

> > > Hi,
> > >
> > > I'm having a little difficulty getting my head round windows integrated
> > > security/impersonation and I'd appreciate a little help with the problem
> > > I'm
> > > trying to solve (or an indication that what I'm trying to do is too hard
> > > to
> > > be worth it!)
> > >
> > > To give you the background: I'm developing a web portal application which
> > > has fairly limited number of users. We're using SQL Server reporting
> > > services. A number of the reports need to be bound to groups of users;
> > > also,
> > > some of the reports need to know the logged-in user to use directly in the
> > > SQL queries. This can, of course, all be done using Windows Integrated
> > > Authentication. Also, another piece of info, I can't justify the cost of
> > > the
> > > Enterprise version of SQL Server and so cannot use a reporting services
> > > custom security extension (eg Form based authentication). Also, I'm
> > > serving
> > > up my reports using the reportviewer custom control, which loads reports
> > > into
> > > an IFrame, so effectively creates its own http requests.
> > >
> > > I have no problems creating accounts on the server for every user. What I
> > > don't like, however, is the integrated security popup box. It's quite ugly
> > > and from a user experience point of view really doesn't fit in with their
> > > expectations of a web application, where they would expect a more forms
> > > based
> > > view. I thought that I might be able to do something in the background
> > > whereby they could login through a form and I could manaully do the
> > > logging
> > > in, and from then on (until timeout) this user would be regarded by the
> > > webapp and report server as the credentials supplied.
> > >
> > > Okay, so I used the demo in msdn:
> > > ms-help://MS.MSDNQTR.2004JUL.1033/cpref/html/frlrfSystemSecurityPrincipalWindowsIdentityClassIm personateTopic1.htm
> > >
> > > and webapp'ed it. This works and I was hoping that if I didn't undo the
> > > impersonation at the end, that all future http requests from this client
> > > would be regarded as the impersonated user, which would obviously enable
> > > someone to login and then when they view reports they would be that user.
> > > I
> > > kinda knew that wasn't going to work and it feels like I might still be
> > > able
> > > to do this by doing something with the security token.
> > >
> > > Is what I'm trying to do mad? Am I going to have to implement my own
> > > HttpHandler and impersonate the user I think someone is, at each request?
> > > It
> > > would be great if there are any tutorials out there. Obviously if it's too
> > > difficult, or will introduce huge security weaknesses in the system then
> > > it's
> > > just not worth it. As I said, all I'm trying to do here is remove the
> > > popup
> > > login box!
> > >
> > > Thanks in advance for your help,
> > >
> > > Phil Aldis
> > >

> >
> >
> >