We have developed a custom asp.net 2.0 RoleProvider to Authorize access to
different areas of our web app so that administrators of our application
could control access rather than IT staff. The custom RoleProvider reads
user and role information from a SQLServer 2005 Database. We are not using a
custom MembershipProvider. We are now trying to integrate Reporting Services
2005 with the Web App. I want the Roles used to authorize access to reports
be the same roles that are used to authorize access to the pages in my web
app. I would like to have reporting services use my custom RoleProvider. It
is my understanding that I need to create a class that implements
IAuthorizationExtension to do this.
I have the example from the Teo Lachev book. Not exacly what i needed, but
of figre if I could get that one running, I could modify it to call my custom
RoleProvider. When I implemented the sample from the book, I get an
exceiption when it calls the BinaryFormatter Deserialize method to
deserialize SecDesc item that was passed to GetAccess. The error message i
get is 'The input stream is not in a valid binary format. The starting
contents (in bytes) are :06-05-00-9c...'
Can anyone how a custom Authorization Extension is supposed to use the
Security descriptors it gets from RS?
Has anyone managed to use asp.net 2.0 RoleProviders with RS2005? Is there
any good documentation on how to implement and deploy an
IAuthorizationExtension? Should I be taking another approach?
It Seems to me that there ought to be [supplied by microsoft] an
implementation of the IAuthorizationExtension that calls a RoleProvider to
determine what groups a user is in, but I have not been able to find it.
Without this ability, the RoleProvider functionality is useless, because IT
staff would need to maintain AD Groups to control access to reports while an
Application Administrator would need to maintain RoleProvider Groups that
control access to my pages. It sounds like if someone wants to use
Reporting services, the should not be using a custom RoleProvider.Just in case anyone else experiences this problem in the future , I thought
I'd document what I've figured out so far. This is probably all buried in
some documentation somewhere, but I've been unable to find it.
When writing my pervious post, I had installed RS2005 and then installed a
custom Authorization Extension and was getting an error saying 'The
input stream is not in a valid binary format...'. when trying to access the
root folder of the report server. I had copied much of the code from the
Lachev book.
The root folder of the report server was created at the time I installed
RS2005. My custom Authorization Extension was not in place at the time the
root folder was created , so the ACL for the folder was created serialized
using the CreateSecurityDescriptor method of the default Authorization
Extension that comes with RS2005 (i.e. the one that works with AD groups).
I could browse to the root folder of the report server at this time with no
problem.
After I installed my custom Authorization Extension and browsed to the root
folder, RS Passed the ACL created and serialized by the default
Authorization Extension to my custom Authorization Extension. This caused
the issue. The CreateSecurityDescriptor and the CheckAccess methods work
hand-in-hand. The ACL create by CreateSecurityDescriptor of the default
Authorization Extension could not be deserialized by the GetAccess method of
my Custom Authorization Extension.
Afterwards, I created a new folder. Because this new folder was created
with my extension in place, the ACL was serialized by my own
CreateSecurityDescriptor method, and thus could be deserialized by my own
GetAccess method with no problem.
I just can't access the root folder after having installedmy extension,
because the security extension was not created by my code!.
"gover" <gover@.discussions.microsoft.com> wrote in message
news:03E811C4-6811-45EB-A071-0CAF14771C28@.microsoft.com...
> We have developed a custom asp.net 2.0 RoleProvider to Authorize access
> to
> different areas of our web app so that administrators of our application
> could control access rather than IT staff. The custom RoleProvider reads
> user and role information from a SQLServer 2005 Database. We are not using
> a
> custom MembershipProvider. We are now trying to integrate Reporting
> Services
> 2005 with the Web App. I want the Roles used to authorize access to
> reports
> be the same roles that are used to authorize access to the pages in my web
> app. I would like to have reporting services use my custom RoleProvider.
> It
> is my understanding that I need to create a class that implements
> IAuthorizationExtension to do this.
> I have the example from the Teo Lachev book. Not exacly what i needed, but
> of figre if I could get that one running, I could modify it to call my
> custom
> RoleProvider. When I implemented the sample from the book, I get an
> exceiption when it calls the BinaryFormatter Deserialize method to
> deserialize SecDesc item that was passed to GetAccess. The error message
> i
> get is 'The input stream is not in a valid binary format. The starting
> contents (in bytes) are :06-05-00-9c...'
> Can anyone how a custom Authorization Extension is supposed to use the
> Security descriptors it gets from RS?
> Has anyone managed to use asp.net 2.0 RoleProviders with RS2005? Is
> there
> any good documentation on how to implement and deploy an
> IAuthorizationExtension? Should I be taking another approach?
>
> It Seems to me that there ought to be [supplied by microsoft] an
> implementation of the IAuthorizationExtension that calls a RoleProvider
> to
> determine what groups a user is in, but I have not been able to find it.
> Without this ability, the RoleProvider functionality is useless, because
> IT
> staff would need to maintain AD Groups to control access to reports while
> an
> Application Administrator would need to maintain RoleProvider Groups that
> control access to my pages. It sounds like if someone wants to use
> Reporting services, the should not be using a custom RoleProvider.
>
>|||Did you ever figure out how to cleare the old security descriptor ?
"gover" wrote:
> Just in case anyone else experiences this problem in the future , I thought
> I'd document what I've figured out so far. This is probably all buried in
> some documentation somewhere, but I've been unable to find it.
> When writing my pervious post, I had installed RS2005 and then installed a
> custom Authorization Extension and was getting an error saying 'The
> input stream is not in a valid binary format...'. when trying to access the
> root folder of the report server. I had copied much of the code from the
> Lachev book.
> The root folder of the report server was created at the time I installed
> RS2005. My custom Authorization Extension was not in place at the time the
> root folder was created , so the ACL for the folder was created serialized
> using the CreateSecurityDescriptor method of the default Authorization
> Extension that comes with RS2005 (i.e. the one that works with AD groups).
> I could browse to the root folder of the report server at this time with no
> problem.
> After I installed my custom Authorization Extension and browsed to the root
> folder, RS Passed the ACL created and serialized by the default
> Authorization Extension to my custom Authorization Extension. This caused
> the issue. The CreateSecurityDescriptor and the CheckAccess methods work
> hand-in-hand. The ACL create by CreateSecurityDescriptor of the default
> Authorization Extension could not be deserialized by the GetAccess method of
> my Custom Authorization Extension.
> Afterwards, I created a new folder. Because this new folder was created
> with my extension in place, the ACL was serialized by my own
> CreateSecurityDescriptor method, and thus could be deserialized by my own
> GetAccess method with no problem.
> I just can't access the root folder after having installedmy extension,
> because the security extension was not created by my code!.
>
> "gover" <gover@.discussions.microsoft.com> wrote in message
> news:03E811C4-6811-45EB-A071-0CAF14771C28@.microsoft.com...
> > We have developed a custom asp.net 2.0 RoleProvider to Authorize access
> > to
> > different areas of our web app so that administrators of our application
> > could control access rather than IT staff. The custom RoleProvider reads
> > user and role information from a SQLServer 2005 Database. We are not using
> > a
> > custom MembershipProvider. We are now trying to integrate Reporting
> > Services
> > 2005 with the Web App. I want the Roles used to authorize access to
> > reports
> > be the same roles that are used to authorize access to the pages in my web
> > app. I would like to have reporting services use my custom RoleProvider.
> > It
> > is my understanding that I need to create a class that implements
> > IAuthorizationExtension to do this.
> >
> > I have the example from the Teo Lachev book. Not exacly what i needed, but
> > of figre if I could get that one running, I could modify it to call my
> > custom
> > RoleProvider. When I implemented the sample from the book, I get an
> > exceiption when it calls the BinaryFormatter Deserialize method to
> > deserialize SecDesc item that was passed to GetAccess. The error message
> > i
> > get is 'The input stream is not in a valid binary format. The starting
> > contents (in bytes) are :06-05-00-9c...'
> >
> > Can anyone how a custom Authorization Extension is supposed to use the
> > Security descriptors it gets from RS?
> >
> > Has anyone managed to use asp.net 2.0 RoleProviders with RS2005? Is
> > there
> > any good documentation on how to implement and deploy an
> > IAuthorizationExtension? Should I be taking another approach?
> >
> >
> > It Seems to me that there ought to be [supplied by microsoft] an
> > implementation of the IAuthorizationExtension that calls a RoleProvider
> > to
> > determine what groups a user is in, but I have not been able to find it.
> > Without this ability, the RoleProvider functionality is useless, because
> > IT
> > staff would need to maintain AD Groups to control access to reports while
> > an
> > Application Administrator would need to maintain RoleProvider Groups that
> > control access to my pages. It sounds like if someone wants to use
> > Reporting services, the should not be using a custom RoleProvider.
> >
> >
> >
> >
>
>
Showing posts with label developed. Show all posts
Showing posts with label developed. Show all posts
Friday, March 30, 2012
Friday, February 24, 2012
I need some advice before starting VB/SQL Project
I am just in the process of learning VB.NET so that I can upsize an access database that I developed for my company.
I need advise on two subjects:
First, I am going to be starting a new VB.NET / SQL project using MSDE installed on my development computer. What do I need to do to allow me to easily deploy the program on several workstations and a dedicated server once development is finished?
Second, I would like to have a transitional period where both the VBA in the current MDB and the new VB.NET project access the same data. The one solution that I came up with was creating queries on the SQL server that pointed to the MDB, then once I am comfortable with the VB.NET end of things I would transfer the data it's self to the SQL server and change the queries to point to the new data location... However I have no idea weather or not this will work or if it is even close to being a good idea.
Any advice would be greatly appreciated.I wouldn't waste my time on developing in Access and then moving to SQL Server. Just start with the latter!|||Michael Kaiser
Brett Smith
Geez I thought I was unique...
Anyway, take rdjabarov's advice...
You can easily set up an Access mdb and link the sql server tables to it...
Don't bother with Jet...or don't you have sql server installed yet?
Or is it an existing application already?
How big is the database (or how big will it be?)
Also, you don't mention anything about stored procedures...
Do you plan on using them...it would be a big plus, especially for you're design implementation...|||Absolutely. Creating queries in SQL Server that point to data in a transitional Access database is going to cause you more trouble than just building the tables in SQL Server to begin with.
Hey, I like Access a lot, but there is really no point in using it in your development if it is not going to be part of your final solution.
If your data is already in Access, then it is worth trying the Upsizing wizard. I've used it once or twice and I seem to recall that it did a decent job. If you need a transitional application, then move your existing forms and code into a Microsoft Access Data Project that is tied directly to your SQL server database.|||Unfortunately I am already up to my eyeballs in Access
This is at the moment the primary issue tracking system for the small consulting firm that I work for. Hundreds of contacts, thousands of related records... and it has only been in use for about 6 months.
What I need to do is develop the project in vb and slowly transfer functionality over as modules get debugged.
To answer the other question about stored procedures, I am definitely going to be using them.|||I'm a little confused (and that's on a good day)...
Is the data centraly located, or does each client have their own copy of the data?|||Then again, I think you would be best off if you transfered the data to Microsoft SQL server and converted your Access database into an Access Data Project while you transition to your final solution.|||The data is centrally located in a mdb that only contains tables and each client has their own MDB file which has all the forms reports and VBA and links to the tables on the main database
I won't even begin to try to explain how this configuration came about, just keep in mind that decisions like that came about via committee and I (the actual developer) was not invited.|||Well, that's not a bad configuration for a distributed Microsoft Acces solution, but it does make your upsizing more difficult.
You could still develop an Access Data Project file and distribute it to your users. If you import your forms and modules it should look identical to them. Somewhere, you are going to have to bite the administrative bullet and come up with the transition strategy that best suits your business.|||I guess at this point I am going to look into an ADP, what I was hoping to avoid was spending any more time in access when it's not in the final plan. I know that the upsize wizard will not work for most of my forms and two of my tables, but I may just have to do it and get it over with|||Just another thought, would it make senct to just migrate the data to SQL and then change the links in the client MDB files to point to the SQL tables via an ODBC connection rather than actually transfer everything over to an ADP?|||I would...
a data source is a data source...
Only downside depends on the complexity of the forms/reports...
could be a lot slower depending on the # of connections opened by a form or report..|||Sure. Just make sure your security is good. Also, chances are good that you performance will be significantly slower than if you used an ADP interface.|||This is looking like my best option.
The last question on that front would be does anyone know if I like an Access MDB to SQL via ODBC can I use a SQL View for the source and meke it appear to Access to be a linked table?
I would only want to do this for two of the tables, because I would like to make some changes to the table field names.|||Yeah...check it out...they'll appear just like tables...
Just make sure that the view is updatable...otherwise it'll be a problem...|||I would get away from linked objects all together and replace them with pass-through queries to guarantee a more-or-less reasonable performance (I still don't understand why you would want to stick to Access to be your middle man.)
And to answer your question, - yes you can set a view as a source for a linked object.|||I think I am on my way!
I am sure that I will be back soon with other questions, but this should at least allow me to get my data onto SQL wile making very minor changes to the current Access database.
I need advise on two subjects:
First, I am going to be starting a new VB.NET / SQL project using MSDE installed on my development computer. What do I need to do to allow me to easily deploy the program on several workstations and a dedicated server once development is finished?
Second, I would like to have a transitional period where both the VBA in the current MDB and the new VB.NET project access the same data. The one solution that I came up with was creating queries on the SQL server that pointed to the MDB, then once I am comfortable with the VB.NET end of things I would transfer the data it's self to the SQL server and change the queries to point to the new data location... However I have no idea weather or not this will work or if it is even close to being a good idea.
Any advice would be greatly appreciated.I wouldn't waste my time on developing in Access and then moving to SQL Server. Just start with the latter!|||Michael Kaiser
Brett Smith
Geez I thought I was unique...
Anyway, take rdjabarov's advice...
You can easily set up an Access mdb and link the sql server tables to it...
Don't bother with Jet...or don't you have sql server installed yet?
Or is it an existing application already?
How big is the database (or how big will it be?)
Also, you don't mention anything about stored procedures...
Do you plan on using them...it would be a big plus, especially for you're design implementation...|||Absolutely. Creating queries in SQL Server that point to data in a transitional Access database is going to cause you more trouble than just building the tables in SQL Server to begin with.
Hey, I like Access a lot, but there is really no point in using it in your development if it is not going to be part of your final solution.
If your data is already in Access, then it is worth trying the Upsizing wizard. I've used it once or twice and I seem to recall that it did a decent job. If you need a transitional application, then move your existing forms and code into a Microsoft Access Data Project that is tied directly to your SQL server database.|||Unfortunately I am already up to my eyeballs in Access
This is at the moment the primary issue tracking system for the small consulting firm that I work for. Hundreds of contacts, thousands of related records... and it has only been in use for about 6 months.
What I need to do is develop the project in vb and slowly transfer functionality over as modules get debugged.
To answer the other question about stored procedures, I am definitely going to be using them.|||I'm a little confused (and that's on a good day)...
Is the data centraly located, or does each client have their own copy of the data?|||Then again, I think you would be best off if you transfered the data to Microsoft SQL server and converted your Access database into an Access Data Project while you transition to your final solution.|||The data is centrally located in a mdb that only contains tables and each client has their own MDB file which has all the forms reports and VBA and links to the tables on the main database
I won't even begin to try to explain how this configuration came about, just keep in mind that decisions like that came about via committee and I (the actual developer) was not invited.|||Well, that's not a bad configuration for a distributed Microsoft Acces solution, but it does make your upsizing more difficult.
You could still develop an Access Data Project file and distribute it to your users. If you import your forms and modules it should look identical to them. Somewhere, you are going to have to bite the administrative bullet and come up with the transition strategy that best suits your business.|||I guess at this point I am going to look into an ADP, what I was hoping to avoid was spending any more time in access when it's not in the final plan. I know that the upsize wizard will not work for most of my forms and two of my tables, but I may just have to do it and get it over with|||Just another thought, would it make senct to just migrate the data to SQL and then change the links in the client MDB files to point to the SQL tables via an ODBC connection rather than actually transfer everything over to an ADP?|||I would...
a data source is a data source...
Only downside depends on the complexity of the forms/reports...
could be a lot slower depending on the # of connections opened by a form or report..|||Sure. Just make sure your security is good. Also, chances are good that you performance will be significantly slower than if you used an ADP interface.|||This is looking like my best option.
The last question on that front would be does anyone know if I like an Access MDB to SQL via ODBC can I use a SQL View for the source and meke it appear to Access to be a linked table?
I would only want to do this for two of the tables, because I would like to make some changes to the table field names.|||Yeah...check it out...they'll appear just like tables...
Just make sure that the view is updatable...otherwise it'll be a problem...|||I would get away from linked objects all together and replace them with pass-through queries to guarantee a more-or-less reasonable performance (I still don't understand why you would want to stick to Access to be your middle man.)
And to answer your question, - yes you can set a view as a source for a linked object.|||I think I am on my way!
I am sure that I will be back soon with other questions, but this should at least allow me to get my data onto SQL wile making very minor changes to the current Access database.
Subscribe to:
Posts (Atom)