Re: Functionality of run-as for Servlets
Your suggestion is very good, but doesn't work, as I understand it, when not using a SecurityManager. Subject.getSubject() returns null. Now I myself think it is a great idea to use a security-manager at all times, but when writing an application it seems like a good idea not to make that assumption. Is it really a requirement to have a SecurityManager for Subject to be useful? It seems like a construct like the one you suggest should work even without one. Cheers, -- Gunnar Gunnar Brading wrote: I have been in need of using the run-as tag in a Tomcat-only environment... Is this possible? Reading the source indicates that it wouldn't be possible to get the information about the role the context currently is in. Using the requests in-role methods of course tells me about the user, and not the context. Have I come to the right conclusion? No ;-) You can get access to the Subject by doing Subject.getSubject(AccessController.getContext()) Reading the specs tells me that the functionality is meant for transferring roles to EJB's. Some documentation I found at Sun indicates though that even web-applications should be able to use this. The way SJSAS 8.x is doing that is by using the Subject and then the principal(s) associated with the Subject. -- Jeanfrancois Anyone got more information about this? Cheers, -- gunnar -- Gunnar Brading, Astrogator AB - High Performance Networks Interactive Media Email; [EMAIL PROTECTED] Address; Rorstrandsgatan 30A, 113 40 STOCKHOLM Office: +46 8 5456 0010 Fax: +46 8 5456 0011 Cellular: +46 70 778 2 877 The scientist describes what is; the engineer creates what never was - Theodore von Karman
Re: Functionality of run-as for Servlets
Following up after some testing I gave up, and just for testing thought I should use the SecurityManager. Always a good idea. But... I got to be stupid or something, but I do not get the run-as to show up anyhow. When not authenticated, the retrieved Subject gives an empty set of principals When authenticated the set of Principals only shows the authenticated users roles. The run-as doesn't seem to affect the Subject as far as I can tell. It should I guess, as Jeanfrancois said. I personally think it should, even without a SecurityManager. Any insights? Cheers, -- Gunnar Gunnar Brading wrote: Your suggestion is very good, but doesn't work, as I understand it, when not using a SecurityManager. Subject.getSubject() returns null. Now I myself think it is a great idea to use a security-manager at all times, but when writing an application it seems like a good idea not to make that assumption. Is it really a requirement to have a SecurityManager for Subject to be useful? It seems like a construct like the one you suggest should work even without one. Cheers, -- Gunnar Gunnar Brading wrote: I have been in need of using the run-as tag in a Tomcat-only environment... Is this possible? Reading the source indicates that it wouldn't be possible to get the information about the role the context currently is in. Using the requests in-role methods of course tells me about the user, and not the context. Have I come to the right conclusion? No ;-) You can get access to the Subject by doing Subject.getSubject(AccessController.getContext()) Reading the specs tells me that the functionality is meant for transferring roles to EJB's. Some documentation I found at Sun indicates though that even web-applications should be able to use this. The way SJSAS 8.x is doing that is by using the Subject and then the principal(s) associated with the Subject. -- Jeanfrancois Anyone got more information about this? Cheers, -- gunnar -- Gunnar Brading, Astrogator AB - High Performance Networks Interactive Media Email; [EMAIL PROTECTED] Address; Rorstrandsgatan 30A, 113 40 STOCKHOLM Office: +46 8 5456 0010 Fax: +46 8 5456 0011 Cellular: +46 70 778 2 877 The scientist describes what is; the engineer creates what never was - Theodore von Karman -- Gunnar Brading, Astrogator AB - High Performance Networks Interactive Media Email; [EMAIL PROTECTED] Address; Rorstrandsgatan 30A, 113 40 STOCKHOLM Office: +46 8 5456 0010 Fax: +46 8 5456 0011 Cellular: +46 70 778 2 877 The scientist describes what is; the engineer creates what never was - Theodore von Karman smime.p7s Description: S/MIME Cryptographic Signature
Functionality of run-as for Servlets
I have been in need of using the run-as tag in a Tomcat-only environment... Is this possible? Reading the source indicates that it wouldn't be possible to get the information about the role the context currently is in. Using the requests in-role methods of course tells me about the user, and not the context. Have I come to the right conclusion? Reading the specs tells me that the functionality is meant for transferring roles to EJB's. Some documentation I found at Sun indicates though that even web-applications should be able to use this. Anyone got more information about this? Cheers, -- gunnar -- Gunnar Brading, Astrogator AB - High Performance Networks Interactive Media Email; [EMAIL PROTECTED] Address; Rorstrandsgatan 30A, 113 40 STOCKHOLM Office: +46 8 5456 0010 Fax: +46 8 5456 0011 Cellular: +46 70 778 2 877 The scientist describes what is; the engineer creates what never was - Theodore von Karman smime.p7s Description: S/MIME Cryptographic Signature
Re: Functionality of run-as for Servlets
Gunnar Brading wrote: I have been in need of using the run-as tag in a Tomcat-only environment... Is this possible? Reading the source indicates that it wouldn't be possible to get the information about the role the context currently is in. Using the requests in-role methods of course tells me about the user, and not the context. Have I come to the right conclusion? No ;-) You can get access to the Subject by doing Subject.getSubject(AccessController.getContext()) Reading the specs tells me that the functionality is meant for transferring roles to EJB's. Some documentation I found at Sun indicates though that even web-applications should be able to use this. The way SJSAS 8.x is doing that is by using the Subject and then the principal(s) associated with the Subject. -- Jeanfrancois Anyone got more information about this? Cheers, -- gunnar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]