|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
can you put a strong name assembly in a role?security so that a privileged assembly can only be called by a specific strong named assembly? I got hopeful when I found out about the strong name condition for a code group in cas, but now it seems like all you can do with cas is define what an assembly can call and never what can call the assembly. I hope I am just missing something obvious. My goal here is to use the privileged application to return credential information to the calling program. I can achieve rights elevation using COM+ and putting a low privileged user in a role for the COM+ app, but this bothers me since if anybody figures out how to call the privileged assembly they can get the credentials. The assembly runs as an account that has privileges in a SQL Server table. If I could simply add a strong named assembly to a role for the com+ app instead of a user or a group, my trouble would be over. Please help with any thoughts on this matter. It will be much appreciated. Daren "ubiquitousspor" <ubiquitouss***@discussions.microsoft.com> wrote in message Sort of, but the protection isn't worth much. You can add (link)demands for news:10136359-B677-4B44-8941-27EC06730221@microsoft.com... > The simple version of my question is this: how can you (or can you) set > security so that a privileged assembly can only be called by a specific > strong named assembly? StrongNameIdentityPermission (or any other identity permission) to the target assembly. However, it's quite trivial for highly privileged code (FullTrust trant or even partial permission set that includes certain key CAS permissions) to bypass such a demand. In addition, in the v. 2.0 framework, all fully trusted assemblies will automatically pass such demands, so this approach will no longer protect against even unintentional misuse of types or members protected by such demands. All in all, not exactly worth the bother... > I got hopeful when I found out about the strong name Well, if you keep digging, you may find identity permission demands > condition for a code group in cas, but now it seems like all you can do > with > cas is define what an assembly can call and never what can call the > assembly. > I hope I am just missing something obvious. advocated for this but, as mentioned above, they're not particular effective against deliberate misuse even in the v. 1.x framework. > My goal here is to use the privileged application to return credential Not really. You would then need to worry about protecting the calling > information to the calling program. I can achieve rights elevation using > COM+ and putting a low privileged user in a role for the COM+ app, but > this > bothers me since if anybody figures out how to call the privileged > assembly > they can get the credentials. The assembly runs as an account that has > privileges in a SQL Server table. > > If I could simply add a strong named assembly to a role for the com+ app > instead of a user or a group, my trouble would be over. assembly. Even if you use low visibility (private, internal) types and members to handle the credentials processing in this assembly, these would be exposed to any highly privileged code via reflection. > Please help with any thoughts on this matter. It will be much Since you already seem to be comfortable with the idea of using a COM+ > appreciated. application to run in an alternate identity context, have you considered performing the subset of operations that involve actual use of the credentials under a similar COM+ app? If this doesn't seem reasonable, might you be willing to explain how the retrieved credentials actually get used? (It's a lot easier to suggest alternate approaches when one knows the goal as well as the problem. <g>) Show quoteHide quote > > Daren > Thanks for your thoughts. I hadn't fully thought out the CAS model since it
is new to me, but it would have sounded like the answer to demand the permission, except for your discouragement of this approach. That seems disappointing to me, but I suppose there must be reasons, or not. "Nicole Calinoiu" wrote: I did consider this, and it seemed perfect until I could not figure out how > Since you already seem to be comfortable with the idea of using a COM+ > application to run in an alternate identity context, have you considered > performing the subset of operations that involve actual use of the > credentials under a similar COM+ app? to lauch a browser window in the proper desktop. If I host the com+ app as a service it can be done if I run it as system, but it runs as a specific user and I can't figure out the UI context switching I guess using window stations or something. Currently over my head. My goal here is to pass the credentials to a control device that hosts a minimal web server, and receives basic authentication over SSL. The server can't be configured for authentication type so I don't know what else to do. The problem exists because the credentials can't be known by the users for business reasons. I think I promised more than I can deliver here. I still have to figure out a safe way to send the credentials to the page on the server, and I played with ideas like modifying the security rule that prevents passing user:password@- type URLs. That can't be good. We might have settled for a way to automate entry of passwords in the protected storage part of the registry and just let the users see the username, but I can't figure that out either and it seems like a bad idea. Anyway, I'm rambling now, and this probably just sounds misguided in the first place, but if you have any suggestions, then thanks in advance. Show quoteHide quote "Nicole Calinoiu" wrote: > "ubiquitousspor" <ubiquitouss***@discussions.microsoft.com> wrote in message > news:10136359-B677-4B44-8941-27EC06730221@microsoft.com... > > The simple version of my question is this: how can you (or can you) set > > security so that a privileged assembly can only be called by a specific > > strong named assembly? > > Sort of, but the protection isn't worth much. You can add (link)demands for > StrongNameIdentityPermission (or any other identity permission) to the > target assembly. However, it's quite trivial for highly privileged code > (FullTrust trant or even partial permission set that includes certain key > CAS permissions) to bypass such a demand. In addition, in the v. 2.0 > framework, all fully trusted assemblies will automatically pass such > demands, so this approach will no longer protect against even unintentional > misuse of types or members protected by such demands. All in all, not > exactly worth the bother... > > > > I got hopeful when I found out about the strong name > > condition for a code group in cas, but now it seems like all you can do > > with > > cas is define what an assembly can call and never what can call the > > assembly. > > I hope I am just missing something obvious. > > Well, if you keep digging, you may find identity permission demands > advocated for this but, as mentioned above, they're not particular effective > against deliberate misuse even in the v. 1.x framework. > > > > My goal here is to use the privileged application to return credential > > information to the calling program. I can achieve rights elevation using > > COM+ and putting a low privileged user in a role for the COM+ app, but > > this > > bothers me since if anybody figures out how to call the privileged > > assembly > > they can get the credentials. The assembly runs as an account that has > > privileges in a SQL Server table. > > > > If I could simply add a strong named assembly to a role for the com+ app > > instead of a user or a group, my trouble would be over. > > Not really. You would then need to worry about protecting the calling > assembly. Even if you use low visibility (private, internal) types and > members to handle the credentials processing in this assembly, these would > be exposed to any highly privileged code via reflection. > > > > Please help with any thoughts on this matter. It will be much > > appreciated. > > Since you already seem to be comfortable with the idea of using a COM+ > application to run in an alternate identity context, have you considered > performing the subset of operations that involve actual use of the > credentials under a similar COM+ app? If this doesn't seem reasonable, > might you be willing to explain how the retrieved credentials actually get > used? (It's a lot easier to suggest alternate approaches when one knows the > goal as well as the problem. <g>) > > > > > > Daren > > > > > "ubiquitousspor" <ubiquitouss***@discussions.microsoft.com> wrote in message <snip>news:8B941039-05C0-497B-8F35-B3B83782B7E0@microsoft.com... > I did consider this, and it seemed perfect until I could not figure out Do you actually need a browser window for this? Is this not something that > how > to lauch a browser window in the proper desktop. If I host the com+ app > as a > service it can be done if I run it as system, but it runs as a specific > user > and I can't figure out the UI context switching I guess using window > stations > or something. Currently over my head. My goal here is to pass the > credentials to a control device that hosts a minimal web server, and > receives > basic authentication over SSL. could be done, for example, by connecting to the device web server via code? Once authenticated, how is the user intended to interact with the device? > The server can't be configured for To be honest, I doubt that the authentication type would make much > authentication type so I don't know what else to do. difference with respect to your focal problem. > The problem exists Hmm... If the credentials are meant to protect the device, and your > because the credentials can't be known by the users for business reasons. application grants the user the same level of access to the device, why do you care if the users actually know the credentials or not? (I can see a few potential reasons, but each has a very different first line solution than what you've described so far.) > I think I promised more than I can deliver here. I still have to figure No, it can't. <g> It also won't really address your central problem, as > out > a safe way to send the credentials to the page on the server, and I played > with ideas like modifying the security rule that prevents passing > user:password@- type URLs. That can't be good. far as I can tell. Show quoteHide quote > > We might have settled for a way to automate entry of passwords in the > protected storage part of the registry and just let the users see the > username, but I can't figure that out either and it seems like a bad idea. > > Anyway, I'm rambling now, and this probably just sounds misguided in the > first place, but if you have any suggestions, then thanks in advance. > > > "Nicole Calinoiu" wrote: > >> "ubiquitousspor" <ubiquitouss***@discussions.microsoft.com> wrote in >> message >> news:10136359-B677-4B44-8941-27EC06730221@microsoft.com... >> > The simple version of my question is this: how can you (or can you) >> > set >> > security so that a privileged assembly can only be called by a specific >> > strong named assembly? >> >> Sort of, but the protection isn't worth much. You can add (link)demands >> for >> StrongNameIdentityPermission (or any other identity permission) to the >> target assembly. However, it's quite trivial for highly privileged code >> (FullTrust trant or even partial permission set that includes certain key >> CAS permissions) to bypass such a demand. In addition, in the v. 2.0 >> framework, all fully trusted assemblies will automatically pass such >> demands, so this approach will no longer protect against even >> unintentional >> misuse of types or members protected by such demands. All in all, not >> exactly worth the bother... >> >> >> > I got hopeful when I found out about the strong name >> > condition for a code group in cas, but now it seems like all you can do >> > with >> > cas is define what an assembly can call and never what can call the >> > assembly. >> > I hope I am just missing something obvious. >> >> Well, if you keep digging, you may find identity permission demands >> advocated for this but, as mentioned above, they're not particular >> effective >> against deliberate misuse even in the v. 1.x framework. >> >> >> > My goal here is to use the privileged application to return credential >> > information to the calling program. I can achieve rights elevation >> > using >> > COM+ and putting a low privileged user in a role for the COM+ app, but >> > this >> > bothers me since if anybody figures out how to call the privileged >> > assembly >> > they can get the credentials. The assembly runs as an account that has >> > privileges in a SQL Server table. >> > >> > If I could simply add a strong named assembly to a role for the com+ >> > app >> > instead of a user or a group, my trouble would be over. >> >> Not really. You would then need to worry about protecting the calling >> assembly. Even if you use low visibility (private, internal) types and >> members to handle the credentials processing in this assembly, these >> would >> be exposed to any highly privileged code via reflection. >> >> >> > Please help with any thoughts on this matter. It will be much >> > appreciated. >> >> Since you already seem to be comfortable with the idea of using a COM+ >> application to run in an alternate identity context, have you considered >> performing the subset of operations that involve actual use of the >> credentials under a similar COM+ app? If this doesn't seem reasonable, >> might you be willing to explain how the retrieved credentials actually >> get >> used? (It's a lot easier to suggest alternate approaches when one knows >> the >> goal as well as the problem. <g>) >> >> >> > >> > Daren >> > >> >> >> The device we are connecting to is a control system with a touch panel
interface. The web server capability of the device allows you to view a virtual exact copy of the touch panel interface and control it as if you were at the device. Basically all we need is to be able to limit the use of this to a small number of machines in our office. If the credentials are known, the device could be accessed from anywhere. The web server on the device can't be configured to limit access only to certain ip addresses, so we thought we should be able to just create a way to automatically pass the credentials using a custom interface only installed on the machines that need the access. Perhaps it would be better to allow knowledge of credentials and limit access to the device to certain hostnames instead, but I don't know how that can be done. Do you? I'm starting to feel that this may be impossible but I always hate to have to accept impossibility so I am pressing on perhaps in futility. Might we implement some sort of intermediary web page on our IIS server? This sounds intriguing. Show quoteHide quote "Nicole Calinoiu" wrote: > "ubiquitousspor" <ubiquitouss***@discussions.microsoft.com> wrote in message > news:8B941039-05C0-497B-8F35-B3B83782B7E0@microsoft.com... > <snip> > > I did consider this, and it seemed perfect until I could not figure out > > how > > to lauch a browser window in the proper desktop. If I host the com+ app > > as a > > service it can be done if I run it as system, but it runs as a specific > > user > > and I can't figure out the UI context switching I guess using window > > stations > > or something. Currently over my head. My goal here is to pass the > > credentials to a control device that hosts a minimal web server, and > > receives > > basic authentication over SSL. > > Do you actually need a browser window for this? Is this not something that > could be done, for example, by connecting to the device web server via code? > Once authenticated, how is the user intended to interact with the device? > > > > > The server can't be configured for > > authentication type so I don't know what else to do. > > To be honest, I doubt that the authentication type would make much > difference with respect to your focal problem. > > > > The problem exists > > because the credentials can't be known by the users for business reasons. > > Hmm... If the credentials are meant to protect the device, and your > application grants the user the same level of access to the device, why do > you care if the users actually know the credentials or not? (I can see a > few potential reasons, but each has a very different first line solution > than what you've described so far.) > > > > > I think I promised more than I can deliver here. I still have to figure > > out > > a safe way to send the credentials to the page on the server, and I played > > with ideas like modifying the security rule that prevents passing > > user:password@- type URLs. That can't be good. > > No, it can't. <g> It also won't really address your central problem, as > far as I can tell. > > > > > > We might have settled for a way to automate entry of passwords in the > > protected storage part of the registry and just let the users see the > > username, but I can't figure that out either and it seems like a bad idea. > > > > Anyway, I'm rambling now, and this probably just sounds misguided in the > > first place, but if you have any suggestions, then thanks in advance. > > > > > > "Nicole Calinoiu" wrote: > > > >> "ubiquitousspor" <ubiquitouss***@discussions.microsoft.com> wrote in > >> message > >> news:10136359-B677-4B44-8941-27EC06730221@microsoft.com... > >> > The simple version of my question is this: how can you (or can you) > >> > set > >> > security so that a privileged assembly can only be called by a specific > >> > strong named assembly? > >> > >> Sort of, but the protection isn't worth much. You can add (link)demands > >> for > >> StrongNameIdentityPermission (or any other identity permission) to the > >> target assembly. However, it's quite trivial for highly privileged code > >> (FullTrust trant or even partial permission set that includes certain key > >> CAS permissions) to bypass such a demand. In addition, in the v. 2.0 > >> framework, all fully trusted assemblies will automatically pass such > >> demands, so this approach will no longer protect against even > >> unintentional > >> misuse of types or members protected by such demands. All in all, not > >> exactly worth the bother... > >> > >> > >> > I got hopeful when I found out about the strong name > >> > condition for a code group in cas, but now it seems like all you can do > >> > with > >> > cas is define what an assembly can call and never what can call the > >> > assembly. > >> > I hope I am just missing something obvious. > >> > >> Well, if you keep digging, you may find identity permission demands > >> advocated for this but, as mentioned above, they're not particular > >> effective > >> against deliberate misuse even in the v. 1.x framework. > >> > >> > >> > My goal here is to use the privileged application to return credential > >> > information to the calling program. I can achieve rights elevation > >> > using > >> > COM+ and putting a low privileged user in a role for the COM+ app, but > >> > this > >> > bothers me since if anybody figures out how to call the privileged > >> > assembly > >> > they can get the credentials. The assembly runs as an account that has > >> > privileges in a SQL Server table. > >> > > >> > If I could simply add a strong named assembly to a role for the com+ > >> > app > >> > instead of a user or a group, my trouble would be over. > >> > >> Not really. You would then need to worry about protecting the calling > >> assembly. Even if you use low visibility (private, internal) types and > >> members to handle the credentials processing in this assembly, these > >> would > >> be exposed to any highly privileged code via reflection. > >> > >> > >> > Please help with any thoughts on this matter. It will be much > >> > appreciated. > >> > >> Since you already seem to be comfortable with the idea of using a COM+ > >> application to run in an alternate identity context, have you considered > >> performing the subset of operations that involve actual use of the > >> credentials under a similar COM+ app? If this doesn't seem reasonable, > >> might you be willing to explain how the retrieved credentials actually > >> get > >> used? (It's a lot easier to suggest alternate approaches when one knows > >> the > >> goal as well as the problem. <g>) > >> > >> > >> > > >> > Daren > >> > > >> > >> > >> > > >
Show quote
Hide quote
"ubiquitousspor" <ubiquitouss***@discussions.microsoft.com> wrote in message Might it be possible to use your network to limit the callers rather than news:1B654B6E-0EA7-4202-B8A6-A16E9C907660@microsoft.com... > The device we are connecting to is a control system with a touch panel > interface. The web server capability of the device allows you to view a > virtual exact copy of the touch panel interface and control it as if you > were > at the device. Basically all we need is to be able to limit the use of > this > to a small number of machines in our office. If the credentials are > known, > the device could be accessed from anywhere. The web server on the device > can't be configured to limit access only to certain ip addresses, so we > thought we should be able to just create a way to automatically pass the > credentials using a custom interface only installed on the machines that > need > the access. attempting to impose this restriction at either endpoint? For example, might your internal routing mechanisms allow you to only route traffic to the device's IP from certain caller IPs? Would adding a firewall or router between the device and the rest of your network be an acceptable option? > Perhaps it would be better to allow knowledge of credentials and Hostnames just map back to IP addresses, except they're even easier to > limit access to the device to certain hostnames instead, spoof. If the device doesn't allow caller control based on IP, then chances are it doesn't allow it based on host name either. > but I don't know how Creating a pass-through page that's hosted on a server that can limit > that can be done. Do you? I'm starting to feel that this may be > impossible > but I always hate to have to accept impossibility so I am pressing on > perhaps > in futility. Might we implement some sort of intermediary web page on our > IIS server? This sounds intriguing. callers based on IP address should be quite viable. However, given that additional programming work would be required, it may be a more expensive than the network approach. Unless your network admin guys have already ruled out a network-based approach, it might be a good idea to talk to them before pursuing anything that requires custom programming... Show quoteHide quote > > > "Nicole Calinoiu" wrote: > >> "ubiquitousspor" <ubiquitouss***@discussions.microsoft.com> wrote in >> message >> news:8B941039-05C0-497B-8F35-B3B83782B7E0@microsoft.com... >> <snip> >> > I did consider this, and it seemed perfect until I could not figure out >> > how >> > to lauch a browser window in the proper desktop. If I host the com+ >> > app >> > as a >> > service it can be done if I run it as system, but it runs as a specific >> > user >> > and I can't figure out the UI context switching I guess using window >> > stations >> > or something. Currently over my head. My goal here is to pass the >> > credentials to a control device that hosts a minimal web server, and >> > receives >> > basic authentication over SSL. >> >> Do you actually need a browser window for this? Is this not something >> that >> could be done, for example, by connecting to the device web server via >> code? >> Once authenticated, how is the user intended to interact with the device? >> >> >> >> > The server can't be configured for >> > authentication type so I don't know what else to do. >> >> To be honest, I doubt that the authentication type would make much >> difference with respect to your focal problem. >> >> >> > The problem exists >> > because the credentials can't be known by the users for business >> > reasons. >> >> Hmm... If the credentials are meant to protect the device, and your >> application grants the user the same level of access to the device, why >> do >> you care if the users actually know the credentials or not? (I can see a >> few potential reasons, but each has a very different first line solution >> than what you've described so far.) >> >> >> >> > I think I promised more than I can deliver here. I still have to >> > figure >> > out >> > a safe way to send the credentials to the page on the server, and I >> > played >> > with ideas like modifying the security rule that prevents passing >> > user:password@- type URLs. That can't be good. >> >> No, it can't. <g> It also won't really address your central problem, as >> far as I can tell. >> >> >> > >> > We might have settled for a way to automate entry of passwords in the >> > protected storage part of the registry and just let the users see the >> > username, but I can't figure that out either and it seems like a bad >> > idea. >> > >> > Anyway, I'm rambling now, and this probably just sounds misguided in >> > the >> > first place, but if you have any suggestions, then thanks in advance. >> > >> > >> > "Nicole Calinoiu" wrote: >> > >> >> "ubiquitousspor" <ubiquitouss***@discussions.microsoft.com> wrote in >> >> message >> >> news:10136359-B677-4B44-8941-27EC06730221@microsoft.com... >> >> > The simple version of my question is this: how can you (or can you) >> >> > set >> >> > security so that a privileged assembly can only be called by a >> >> > specific >> >> > strong named assembly? >> >> >> >> Sort of, but the protection isn't worth much. You can add >> >> (link)demands >> >> for >> >> StrongNameIdentityPermission (or any other identity permission) to the >> >> target assembly. However, it's quite trivial for highly privileged >> >> code >> >> (FullTrust trant or even partial permission set that includes certain >> >> key >> >> CAS permissions) to bypass such a demand. In addition, in the v. 2.0 >> >> framework, all fully trusted assemblies will automatically pass such >> >> demands, so this approach will no longer protect against even >> >> unintentional >> >> misuse of types or members protected by such demands. All in all, not >> >> exactly worth the bother... >> >> >> >> >> >> > I got hopeful when I found out about the strong name >> >> > condition for a code group in cas, but now it seems like all you can >> >> > do >> >> > with >> >> > cas is define what an assembly can call and never what can call the >> >> > assembly. >> >> > I hope I am just missing something obvious. >> >> >> >> Well, if you keep digging, you may find identity permission demands >> >> advocated for this but, as mentioned above, they're not particular >> >> effective >> >> against deliberate misuse even in the v. 1.x framework. >> >> >> >> >> >> > My goal here is to use the privileged application to return >> >> > credential >> >> > information to the calling program. I can achieve rights elevation >> >> > using >> >> > COM+ and putting a low privileged user in a role for the COM+ app, >> >> > but >> >> > this >> >> > bothers me since if anybody figures out how to call the privileged >> >> > assembly >> >> > they can get the credentials. The assembly runs as an account that >> >> > has >> >> > privileges in a SQL Server table. >> >> > >> >> > If I could simply add a strong named assembly to a role for the com+ >> >> > app >> >> > instead of a user or a group, my trouble would be over. >> >> >> >> Not really. You would then need to worry about protecting the calling >> >> assembly. Even if you use low visibility (private, internal) types >> >> and >> >> members to handle the credentials processing in this assembly, these >> >> would >> >> be exposed to any highly privileged code via reflection. >> >> >> >> >> >> > Please help with any thoughts on this matter. It will be much >> >> > appreciated. >> >> >> >> Since you already seem to be comfortable with the idea of using a COM+ >> >> application to run in an alternate identity context, have you >> >> considered >> >> performing the subset of operations that involve actual use of the >> >> credentials under a similar COM+ app? If this doesn't seem >> >> reasonable, >> >> might you be willing to explain how the retrieved credentials actually >> >> get >> >> used? (It's a lot easier to suggest alternate approaches when one >> >> knows >> >> the >> >> goal as well as the problem. <g>) >> >> >> >> >> >> > >> >> > Daren >> >> > >> >> >> >> >> >> >> >> >> Thanks for your input, Nicole. I think I will try talking to the network
guys, but it might not be doable given that there are over 50 of these devices distributed around the campus. I will see if they have any input, but I do fear it will come down to a custom program or nothing in the end. Thanks again for your time. Show quoteHide quote "Nicole Calinoiu" wrote: > "ubiquitousspor" <ubiquitouss***@discussions.microsoft.com> wrote in message > news:1B654B6E-0EA7-4202-B8A6-A16E9C907660@microsoft.com... > > The device we are connecting to is a control system with a touch panel > > interface. The web server capability of the device allows you to view a > > virtual exact copy of the touch panel interface and control it as if you > > were > > at the device. Basically all we need is to be able to limit the use of > > this > > to a small number of machines in our office. If the credentials are > > known, > > the device could be accessed from anywhere. The web server on the device > > can't be configured to limit access only to certain ip addresses, so we > > thought we should be able to just create a way to automatically pass the > > credentials using a custom interface only installed on the machines that > > need > > the access. > > Might it be possible to use your network to limit the callers rather than > attempting to impose this restriction at either endpoint? For example, > might your internal routing mechanisms allow you to only route traffic to > the device's IP from certain caller IPs? Would adding a firewall or router > between the device and the rest of your network be an acceptable option? > > > > Perhaps it would be better to allow knowledge of credentials and > > limit access to the device to certain hostnames instead, > > Hostnames just map back to IP addresses, except they're even easier to > spoof. If the device doesn't allow caller control based on IP, then chances > are it doesn't allow it based on host name either. > > > but I don't know how > > that can be done. Do you? I'm starting to feel that this may be > > impossible > > but I always hate to have to accept impossibility so I am pressing on > > perhaps > > in futility. Might we implement some sort of intermediary web page on our > > IIS server? This sounds intriguing. > > Creating a pass-through page that's hosted on a server that can limit > callers based on IP address should be quite viable. However, given that > additional programming work would be required, it may be a more expensive > than the network approach. Unless your network admin guys have already > ruled out a network-based approach, it might be a good idea to talk to them > before pursuing anything that requires custom programming... > > > > > > > > "Nicole Calinoiu" wrote: > > > >> "ubiquitousspor" <ubiquitouss***@discussions.microsoft.com> wrote in > >> message > >> news:8B941039-05C0-497B-8F35-B3B83782B7E0@microsoft.com... > >> <snip> > >> > I did consider this, and it seemed perfect until I could not figure out > >> > how > >> > to lauch a browser window in the proper desktop. If I host the com+ > >> > app > >> > as a > >> > service it can be done if I run it as system, but it runs as a specific > >> > user > >> > and I can't figure out the UI context switching I guess using window > >> > stations > >> > or something. Currently over my head. My goal here is to pass the > >> > credentials to a control device that hosts a minimal web server, and > >> > receives > >> > basic authentication over SSL. > >> > >> Do you actually need a browser window for this? Is this not something > >> that > >> could be done, for example, by connecting to the device web server via > >> code? > >> Once authenticated, how is the user intended to interact with the device? > >> > >> > >> > >> > The server can't be configured for > >> > authentication type so I don't know what else to do. > >> > >> To be honest, I doubt that the authentication type would make much > >> difference with respect to your focal problem. > >> > >> > >> > The problem exists > >> > because the credentials can't be known by the users for business > >> > reasons. > >> > >> Hmm... If the credentials are meant to protect the device, and your > >> application grants the user the same level of access to the device, why > >> do > >> you care if the users actually know the credentials or not? (I can see a > >> few potential reasons, but each has a very different first line solution > >> than what you've described so far.) > >> > >> > >> > >> > I think I promised more than I can deliver here. I still have to > >> > figure > >> > out > >> > a safe way to send the credentials to the page on the server, and I > >> > played > >> > with ideas like modifying the security rule that prevents passing > >> > user:password@- type URLs. That can't be good. > >> > >> No, it can't. <g> It also won't really address your central problem, as > >> far as I can tell. > >> > >> > >> > > >> > We might have settled for a way to automate entry of passwords in the > >> > protected storage part of the registry and just let the users see the > >> > username, but I can't figure that out either and it seems like a bad > >> > idea. > >> > > >> > Anyway, I'm rambling now, and this probably just sounds misguided in > >> > the > >> > first place, but if you have any suggestions, then thanks in advance. > >> > > >> > > >> > "Nicole Calinoiu" wrote: > >> > > >> >> "ubiquitousspor" <ubiquitouss***@discussions.microsoft.com> wrote in > >> >> message > >> >> news:10136359-B677-4B44-8941-27EC06730221@microsoft.com... > >> >> > The simple version of my question is this: how can you (or can you) > >> >> > set > >> >> > security so that a privileged assembly can only be called by a > >> >> > specific > >> >> > strong named assembly? > >> >> > >> >> Sort of, but the protection isn't worth much. You can add > >> >> (link)demands > >> >> for > >> >> StrongNameIdentityPermission (or any other identity permission) to the > >> >> target assembly. However, it's quite trivial for highly privileged > >> >> code > >> >> (FullTrust trant or even partial permission set that includes certain > >> >> key > >> >> CAS permissions) to bypass such a demand. In addition, in the v. 2.0 > >> >> framework, all fully trusted assemblies will automatically pass such > >> >> demands, so this approach will no longer protect against even > >> >> unintentional > >> >> misuse of types or members protected by such demands. All in all, not > >> >> exactly worth the bother... > >> >> > >> >> > >> >> > I got hopeful when I found out about the strong name > >> >> > condition for a code group in cas, but now it seems like all you can > >> >> > do > >> >> > with > >> >> > cas is define what an assembly can call and never what can call the > >> >> > assembly. > >> >> > I hope I am just missing something obvious. > >> >> > >> >> Well, if you keep digging, you may find identity permission demands > >> >> advocated for this but, as mentioned above, they're not particular > >> >> effective > >> >> against deliberate misuse even in the v. 1.x framework. > >> >> > >> >> > >> >> > My goal here is to use the privileged application to return > >> >> > credential > >> >> > information to the calling program. I can achieve rights elevation > >> >> > using > >> >> > COM+ and putting a low privileged user in a role for the COM+ app, > >> >> > but > >> >> > this > >> >> > bothers me since if anybody figures out how to call the privileged > >> >> > assembly > >> >> > they can get the credentials. The assembly runs as an account that > >> >> > has > >> >> > privileges in a SQL Server table. > >> >> > > >> >> > If I could simply add a strong named assembly to a role for the com+ > >> >> > app > >> >> > instead of a user or a group, my trouble would be over. > >> >> > >> >> Not really. You would then need to worry about protecting the calling > >> >> assembly. Even if you use low visibility (private, internal) types > >> >> and > >> >> members to handle the credentials processing in this assembly, these > >> >> would > >> >> be exposed to any highly privileged code via reflection. > >> >> > >> >> > >> >> > Please help with any thoughts on this matter. It will be much > >> >> > appreciated. > >> >> > >> >> Since you already seem to be comfortable with the idea of using a COM+ > >> >> application to run in an alternate identity context, have you > >> >> considered > >> >> performing the subset of operations that involve actual use of the > >> >> credentials under a similar COM+ app? If this doesn't seem > >> >> reasonable, > >> >> might you be willing to explain how the retrieved credentials actually > >> >> get > >> >> used? (It's a lot easier to suggest alternate approaches when one > >> >> knows > >> >> the > >> >> goal as well as the problem. <g>) > >> >> > >> >> > >> >> > > >> >> > Daren > >> >> > > >> >> > >> >> > >> >> > >> > >> > >> > > > 
Other interesting topics
Can't determine if a file exists
X509 digital certificate for offline solution How to send certificate for client authentication? MD5 or SHA1 or ??? IIS Delegation 'System.Security.SecurityException' when running .exe file from ot String to byte[] & back using Base64 Extra '\0' chars after decryption CAS Permission Sets asp.net err |
|||||||||||||||||||||||
