Menu
▾
▴
jboss-dev-forums
|
From: abelapurkar <nu...@jb...> - 2005-07-25 09:47:35
|
I essentially started with the "in-memory" JACC provider that comes out-of-the-box with JBoss 4.0.2 and enhanced it to include the mapping between the JACC Permission classes and the corresponding XACML constructs. (So, for example, the commit method was enhanced to include code for generating the XACML policy sets etc.) In my version of the provider, I've used the open source XACML implementation from Sun (http://sunxacml.sourceforge.net) as the underlying framework for the XACML constructs. This framework provides, out-of-the-box, a very simple file-based policy finder module (intended for use only as a sample). I?m using this finder in my JACC provider. So, the XACML policy set(s) for applications are written out into flat files during app deployment; these files are then searched at policy enforcement time. A file-based approach is clearly not the most performant/scalable of options, and needs to be reworked. An aside: while testing my provider, I noticed that unchecked WebUserDataPermission instances were not being generated for a deployed application as expected. Briefly, the problem seems to be as follows. Line # 180 of the file "WebPermissionMapping.java" reads while (roles.hasNext()). However, this loop is always skipped, since the roles Iterator is never re-initialized after the previous loop (line # 157) has completed its run. At first glance, it would seem that the way to fix this is to change line #179 to read roles = info.getTransportMethods(). However, after having made that change, I found that unchecked WebUserDataPermission instances were certainly getting generated, but not all of them seemed to be quite the right ones I was expecting. I've not had a chance to follow up on this point since. This needs to be revisited, to confirm whether there is indeed a problem. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886350#3886350 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886350 |
|
From: tcherel <nu...@jb...> - 2005-07-25 13:07:29
|
There is a very good chance that you guys already thought about that, but just in case.... I think that the way you can dynamically (at login time) define the roles of a user by creating a custom JAAS login module is very useful. An very often, this is all that is needed. I understand that a custom JACC provider can do more, but I think it will be a pain if a full blown provider (or a full blown set of custom JACC policy) has to be defined if the only thing that is needed is to be able to specify what are the roles of a given user. May be the future default JBoss JACC provider should have multiple extension points (JBoss specific) where a user can simply overwrite the way roles are retrieved for a user, the way roles are associated to resources and the way permissions are checked (or something like that). Users will then be able to easily "pick and choose" which part of the default JACC provider they want to customize for their needs. Thomas View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886377#3886377 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886377 |
|
From: <sco...@jb...> - 2005-07-25 14:38:38
|
Of course, that is the jboss way. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886401#3886401 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886401 |
|
From: tcherel <nu...@jb...> - 2005-07-25 14:40:34
|
Cool :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886402#3886402 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886402 |
|
From: <sco...@jb...> - 2005-07-25 14:45:03
|
Create a jira issue for the unchecked roles issue so I can ensure the units tests are covering the usage. I'll validate the current roles iterator issue around the transport settings. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886403#3886403 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886403 |
|
From: mholzner <nu...@jb...> - 2005-07-25 18:04:46
|
What about a JACC module descriptor similar to login-config.xml ? Or even make JACC a part of login-config.xml ? After all it seems that the login module and the jacc module have to work together. JACC modules could have a contract similar to JAAS modules (stackable etc.), and should be just as easy to configure per application. I'd also like to mention that this module should allow to be extended to cover access control checks for things like portal resources, or workflow processed, etc, so that multiple PEP interceptors could call into one central PDP (via the JACC impl). I have a document written up describing one possible way (based on the 4.0.2 jacc implementation classes) that I could forward you if you are interested. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886448#3886448 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886448 |
|
From: <sco...@jb...> - 2005-07-25 18:57:45
|
Yes send the doc so it can be incorporated into this thread. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886468#3886468 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886468 |
|
From: mholzner <nu...@jb...> - 2005-07-27 18:27:38
|
here is the short of it:
1) requirements and goals:
* JACC implementations need to be pluggable similar to JAAS modules
* JACC modules need to be configurable per application
* the current JACC implementation needs to be extended to allow other then J2EE resources to check access control through the same mechanism (portal resources for instance)
* the JACC module should allow for more dynamic features , such as access check for portal pages that were created after the portal was deployed
* all JEMS components need to use a unified way to check access control (through JACC; to allow easy configuration of a single PDP)
* static role assignment (in the login module) imposes too many restrictions (think: user is in role 'bookkeeper' from 9 to 5 only). As a result, for more advanced security scenarios, the JACC provider needs to be the one that handles role memberships (dynamically)
2) implementation details:
* JACC modules can be written against a defined API (SPI) that would need to be created
* JACC modules can be configured per application (login?config.xml ?)
* JACC modules could potentially be stackable ((static)J2EE module, Portal module, jBPM module, custom module...) similar to (but far more flexible then) DelegatingPolicy
* container code (interceptors) checks access via an abstracted API
very simplified:
| Security.implies(permission type, subject, resource, action)
|
where permission type is one of J2EE, Portal, ....
* deployers can discover the configured JACC module and add the correct permissions
* all permission types extend java.security.Permission
* the abstracted API news up the correct Permission class (based on the permission type) and calls into a deeper layer
* this deeper layer reads the configured JACC module(s), loads them, and performs the access check with them
* the JAAS and JACC modules need to share some state to allow the JACC provider to get to SAML assertions etc. This would potentially be done via special principals in the subject
* if no JACC provider is configured for an app, the JBoss default one is used
3) questions and food for thought:
* during our discussion around this topic we realized that most applications up the stack (Portal, BPM, WSRP, ...) all need to handle "identity as data" as well. Meaning: they all need to access user attributes in one form or another. We believe that this topic needs to be considered as well when we try to solve JAAS, JACC , RBAC , SAML,... in this layer.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886900#3886900
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886900
|
|
From: <sco...@jb...> - 2005-08-10 15:49:25
|
Yes, we do need the ability to configure the jacc modules per application. Part of this is a much better notion of correlating the jacc policy context id with a deployment. Today its based on the deployment jar, but there needs to be support for externalization of this id for easy correlation with the external security stores. We do need a coupling of the authentication and authorization layers through the authentication Subject. Today we do not support a notion of being able to authenticate, and using only the Subject, execute as the subject. It would require a custom login module that could validate that the doAs Subject is in fact one that has been authenticated, and still has a valid cache state. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3889286#3889286 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3889286 |
|
From: tcherel <nu...@jb...> - 2005-08-10 16:46:51
|
If I may add a few possible requirements on the coupling between authentication and authorization (and related): 1) Definitely allow a doAs model on an EJB client application. This should allow a singel application to authenticate multiple users (if needed) and decide which user to use when and for which operations (quite useful in multi-tiers environments). 2) But doAs model can sometime be painful to program with (delegate class needed for all actions). There should be a way to also set the "current subject" for the current thread or for all threads (or groups or all JVM) to make single-user application easy to write. 3) Being able to configure the server so java security is actually enforced (all actions executed on the server side are done within a doAs block). This will allow java security policies to be defined on the server side if needed. 4) A tighter integration between the client JAAS login modules and the server ones will be nice: - Calling LoginContext.login on the client should go through the client side JAAS modules, then subject is sent to the server and server side JAAS modules are then executed. - Any custom principal (or credential or others) added to the Subject during client side authentication should be available in the Subject provided to the server side JAAS modules. - Any custom principal (or credential or others) added to the Subject during server side authentication should be available in the Subject on the client side after authentication process is finished. May be a configurable mechansim to decide what is "sent back" or not will be nice as well. 5) Probably linked to point 3) above, being able to retrieve the current subject in any EJB component code (like within a session bean operation). All these requirements have one goal in mind: making authentication/authorization more flexible and "easily" customizable. At least these are the kind of things I would have loved to see in one of my recent project :-) I think similar flexibility should also be provided through the web container. My understanding in this area is not as good as on the pure EJB client, so it is harder for me to define some precise requirements, but some of the ideas are as follow: 1) Being able to get the current Subject in servlet code, including any custom principals (or others) that have been added to it. 2) Some FORM authentication extensions where extra form fields (or even HTTP headers) can be used for the authentication process (can be accessed in the JAAS login module). Something that will allow similar custom authentications that can be done with custom subject principals sent from the client. I also have a few more ideas that I need to formalize a little better arround SSO capabilities. Basically, with some of the JDK provided login modules (NTSystem, Kerberos and Unix), it should be possible to support SSO from an EJB client without too much pain. What I mean by SSO is being able to propagate the id from the current user of the client machine (Unix or windows user id) without having to ask the user to provide user name and password again (he already did it when login to his machine). Thomas View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3889293#3889293 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3889293 |
|
From: ErikEngerd2 <nu...@jb...> - 2005-08-10 18:16:46
|
Hi, Just had a look at the JACC specification and one thing I noticed is that this interface is a bit specific towards role based security and supporting the role based security model of J2EE. In addition, we also need a method for supporting JAAS based authorization in J2EE applications. That is, where the application defines custom security Permissions for itself. Just to give an example, I am considering to write a J2EE application that uses custom Permission objects to represent permissions to resources. The security model behind it might or might not be based on role based security. In other words, what I need is a custom set of Policy rules for a J2EE application in addition to those rules already in effect in my environment. This wouldn't be done in the form of a Policy replacement, of course, since it should be impossible to override server policies, but still a mechanism for this is needed. If I am correct, JACC only addresses the problem of supporting the current J2EE security model through JAAS and this aim is insufficient for my application. Cheers Erik View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3889312#3889312 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3889312 |
|
From: piratepete <nu...@jb...> - 2005-08-18 17:48:44
|
Scott: I've been looking at this for personal reasons (lol, trying to convince Ivelin to hire me) but I wrote an article for TSS on SAML and my desire is to create a SAML server and complete administration app for JBoss. I like that SAML could be used to communicate these "identity" things, but my thoughts are to use e.g. HSQL to house the identity data, provide an administration thereof, and use SAML with JAAS to do multi-domain authenticates and authorization for businesses. I have been thinking of using combination JAAS with a SAML identity service but if extending JAAS across contexts is possible, that would be better. In any event, "descripted" security for multi-domain identity management would be sweet. It's possible I think. I recently took a job to lead a large project using BEA WebLogic servers but I would like solve this one (extended JAAS, SAML, etc. multi-domain identity management) using JBoss using only J2EE (complete non-proprietary). I'll keep posting here, since Ivelin pointed me in the right direction. My article on TSS is here http://www.theserverside.com/articles/article.tss?l=SAML Take a look, it's somewhat mousetrap but I understand what the problem is, I just haven't found the exact solution yet. piratepete aka (David Whitehurst) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3890635#3890635 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3890635 |
|
From: <ani...@jb...> - 2005-08-18 18:51:06
|
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3890653#3890653 is a good place to discuss SAML, Identity Management and JBoss. :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3890654#3890654 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3890654 |
|
From: <sco...@jb...> - 2005-09-13 18:33:37
|
So the DelegatingPolicy used as part of the default jboss jacc provider has been extended to support a set of external permissions specified via the ExternalPermissionTypes: | <mbean code="org.jboss.security.jacc.DelegatingPolicy" | name="jboss.security:service=JaccPolicyProvider" | xmbean-dd=""> | <xmbean> | <attribute access="read-only" getMethod="getPolicyProxy"> | <description>The java.security.Policy implementation</description> | <name>PolicyProxy</name> | <type>java.security.Policy</type> | </attribute> | <attribute access="read-write" getMethod="getExternalPermissionTypes" | setMethod="setExternalPermissionTypes"> | <description>The types of non-javax.security.jacc permissions that | should be validated against this policy</description> | <name>ExternalPermissionTypes</name> | <type>[Ljava.lang.Class;</type> | </attribute> | <operation> | <name>listContextPolicies</name> | <return-type>java.lang.String</return-type> | </operation> | </xmbean> | <!-- Not used, just here to test that custom permissions don't break the | current behavior of javax.security.jacc.* permissions. | --> | <attribute name="ExternalPermissionTypes">org.jboss.security.srp.SRPPermission</attribute> | </mbean> | This is in the 4.0 codebase for 4.0.3 but won't be a documented feature until 4.0.4. Deployers can introduce custom permissions that associated security interceptors enforce and use the default jboss jacc provider in a somewhat pass-through manner. A usecase where a null ProtectionDomain was passed to the jacc Policy came up and this is not handled gracefully today. The question is what meaning should be attached to a null ProtectionDomain. One suggestion was that the PolicyContext subject should be consulted. This I do not agree with. Another alternative would be some guest identity similar to the unauthenticatedIdentity notion supported by the login modules. Another is to simply fail, albeit more gracefully than an NPE, as identity is not the responsibility of the jacc provider. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3894504#3894504 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3894504 |
|
From: <sco...@jb...> - 2005-09-13 18:37:02
|
"piratepete" wrote : Scott: | | I've been looking at this for personal reasons (lol, trying to convince Ivelin to hire me) but I wrote an article for TSS on SAML and my desire is to create a SAML server and complete administration app for JBoss. | | I like that SAML could be used to communicate these "identity" things, but my thoughts are to use e.g. HSQL to house the identity data, provide an administration thereof, and use SAML with JAAS to do multi-domain authenticates and authorization for businesses. | | I have been thinking of using combination JAAS with a SAML identity service but if extending JAAS across contexts is possible, that would be better. In any event, "descripted" security for multi-domain identity management would be sweet. It's possible I think. | | I recently took a job to lead a large project using BEA WebLogic servers but I would like solve this one (extended JAAS, SAML, etc. multi-domain identity management) using JBoss using only J2EE (complete non-proprietary). I'll keep posting here, since Ivelin pointed me in the right direction. My article on TSS is here http://www.theserverside.com/articles/article.tss?l=SAML Take a look, it's somewhat mousetrap but I understand what the problem is, I just haven't found the exact solution yet. | | piratepete aka (David Whitehurst) The problem today is that identity today, and even authentication is way too underspecified to have any truly portable security solution in J2EE(Java EE now) servers. Without support of something like the JSR-196 authentication contract there will be nontrivial server specific integration, and security scenarios that don't map well because they are underspecified in the specs. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3894506#3894506 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3894506 |
|
From: zumrani <do-...@jb...> - 2005-09-20 17:04:10
|
"sco...@jb..." wrote : So the DelegatingPolicy used as part of the default jboss jacc provider has been extended to support a set of external permissions specified via the ExternalPermissionTypes: | | | | <mbean code="org.jboss.security.jacc.DelegatingPolicy" | | name="jboss.security:service=JaccPolicyProvider" | | xmbean-dd=""> | | <xmbean> | | <attribute access="read-only" getMethod="getPolicyProxy"> | | <description>The java.security.Policy implementation</description> | | <name>PolicyProxy</name> | | <type>java.security.Policy</type> | | </attribute> | | <attribute access="read-write" getMethod="getExternalPermissionTypes" | | setMethod="setExternalPermissionTypes"> | | <description>The types of non-javax.security.jacc permissions that | | should be validated against this policy</description> | | <name>ExternalPermissionTypes</name> | | <type>[Ljava.lang.Class;</type> | | </attribute> | | <operation> | | <name>listContextPolicies</name> | | <return-type>java.lang.String</return-type> | | </operation> | | </xmbean> | | <!-- Not used, just here to test that custom permissions don't break the | | current behavior of javax.security.jacc.* permissions. | | --> | | <attribute name="ExternalPermissionTypes">org.jboss.security.srp.SRPPermission</attribute> | | </mbean> | | | | This is in the 4.0 codebase for 4.0.3 but won't be a documented feature until 4.0.4. Deployers can introduce custom permissions that associated security interceptors enforce and use the default jboss jacc provider in a somewhat pass-through manner. | | A usecase where a null ProtectionDomain was passed to the jacc Policy came up and this is not handled gracefully today. The question is what meaning should be attached to a null ProtectionDomain. One suggestion was that the PolicyContext subject should be consulted. This I do not agree with. | | Another alternative would be some guest identity similar to the unauthenticatedIdentity notion supported by the login modules. Another is to simply fail, albeit more gracefully than an NPE, as identity is not the responsibility of the jacc provider. | I agree that we need to attach appropriate meaning to null ProtectionDomain(PD). I am not the expert on the subject, but it looks like that ProtectionDomain is part of legacy Policy API which is carried forward into JACC. Except Principal[], JACC does not care about other properties of PD. Moreover, from the application's point of view, if it is doing dynamic resources/permissions, it relies on the container to find the appropriate Subject/Identity of the user. From that perspective a null PD could mean that the container should get one for the application. Without container finding the identity, the application will be forced to create a dummy PD containing Principal[] from the PolicyContext. Though it is possible, but from the application's perspective it is cumbersome to do do. Hence I feel that if PD is null then the JACC layer should find the appropriate Identity/Subject. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3895832#3895832 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3895832 |
|
From: <sco...@jb...> - 2005-09-20 17:56:43
|
The ProtectionDomain is not a legacy api. It just happens that today the CodeSource is not used by the current JAAC policy implementation. It certainly will be usable in the future, and this is the way most people configure their java2 security policies. "zumrani" wrote : | From that perspective a null PD could mean that the container should get one for the application. Without container finding the identity, the application will be forced to create a dummy PD containing Principal[] from the PolicyContext. Though it is possible, but from the application's perspective it is cumbersome to do do. Hence I feel that if PD is null then the JACC layer should find the appropriate Identity/Subject. | Its wrong to consider that the application is being forced to determine the caller identity. JACC is an authorization contract, not authentication. If you are not leveraging the current caller information established by the container, you are replacing this and as such, assuming the role of determining the authenticated identity. The only question here is whether there should be an application pluggable policy for mapping an unauthenticated caller to a particular PD. The JAAS login modules already have a notion of unauthenticatedIdentity, and if a secured resource is hit, this identity will be established. You really need to describe exactly what the context of the null identity is as it seems to me that you are wanting a caller identity even in the context of accessing an unsecured resource. This is an ambiguous part of the servlet security contract and tomcat does not call out to its Realm to trigger any identity authentication for such a resource. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3895845#3895845 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3895845 |
|
From: mholzner <do-...@jb...> - 2005-09-20 18:48:21
|
despite the danger of beating a dead horse, what is the difference between what the current code does, and the proposal of providing a fallback inside the policy? Right now JaccAuthorizationRealm.establishSubjectContext() does exactly what this argument is about. It first checks the PolicyContext for an available Subject, and only if that is not there, it falls back to try and make sense out of the provided principal (which comes from the HttpServletRequest.getCallerPrincipal()) So why not have the Policy first check the ProtectionDomain, and if none is provided, fall back to the PolicyContext and get the Subject from there, rather then throwing a SecurityException if no PD is provided. I don't see where this would introduce any more or less authorization related functionality then what the current JACC code does already.... I have to admit that I'm not an expert in this field, but I don't understand your argumentation. Feel free to ignore me if this is starting to be a silly argument, but I just don't get it so far. After all this is not critical, we can go either way in the implementation, this is only for my ego. I'd like to understand it ;) The other argument that I wanted to raise is that of custom user code that would like to use this security feature. What if a Servlet or a Portlet wants to create new permission classes and do security checks against the policy with them? Wouldn't it be better to provide a simplified API that takes care of the principal/subject determination rather then forcing that client code to get the subject from the PolicyContext (which as I understand it, would require the custom code to be configured in the J2SE policy file to be allowed to access the subject via the PolicyContext....) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3895857#3895857 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3895857 |
|
From: <sco...@jb...> - 2005-09-20 20:18:15
|
Something has to set the caller identity. Any fallback has to rely on some component establishing the caller identity. The PolicyContext is not magically populated by nothing out of the ether surrounding the jboss server. Its populated by the authentication interceptors in the web and ejb containers. The simplified api is a dicussion for the authentication service (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=67191). Once simple change could be an extension to the PolicyContext is a ProtectionDomain handler. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3895873#3895873 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3895873 |
|
From: mholzner <do-...@jb...> - 2005-10-17 00:57:34
|
I'm using this technique in the portal, and everything works as expected. Everything but one thing: the configured permission class is not added to the external permission types. So when I place the following mbean into the jboss-service.xml :
| <mbean
| code="org.jboss.security.jacc.DelegatingPolicy"
| name="jboss.security:service=JaccPolicyProvider"
| xmbean-dd="">
| <xmbean>
| <attribute access="read?only" getMethod="getPolicyProxy">
| <description>The java.security.Policy implementation</description>
| <name>PolicyProxy</name>
| <type>java.security.Policy</type>
| </attribute>
| <attribute access="read?write" getMethod="getExternalPermissionTypes" setMethod="setExternalPermissionTypes">
| <description>The types of non?javax.security.jacc permissions to validate against this policy</description>
| <name>ExternalPermissionTypes</name>
| <type>[Ljava.lang.Class;</type>
| </attribute>
| <operation>
| <name>listContextPolicies</name>
| <return-type>java.lang.String</return-type>
| </operation>
| </xmbean>
| <attribute name="ExternalPermissionTypes">org.jboss.portal.core.security.jacc.PortalObjectPermission</attribute>
| </mbean>
|
and in code I do :
| Policy policy = Policy.getPolicy();
| if (policy instanceof DelegatingPolicy){
|
| DelegatingPolicy delegatingPolicy = (DelegatingPolicy)policy;
| Class[] types = delegatingPolicy.getExternalPermissionTypes();
|
then types.length is always 0
I can work around it by testing for this condition and setting the permission class 'by hand', but that introduces code dependency to 4.0.3
My question is: is there something I'm doing wrong, or is the external permission types injection not working here?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3901426#3901426
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3901426
|
|
From: <sco...@jb...> - 2005-10-17 11:27:52
|
How is this being installed as the java.security.Policy? Just creating a DelegatingPolicy via an xmbean does not do this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3901494#3901494 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3901494 |
|
From: mholzner <do-...@jb...> - 2005-10-17 14:22:51
|
in the same jboss-service.xml I also have : | <mbean | code="org.jboss.security.jacc.SecurityService" | name="jboss.security:service=JACCSecurityService" | xmbean-dd=""> | <xmbean> | <description>The JACC security Policy service</description> | <operation> | <description>The start lifecycle operation</description> | <name>start</name> | </operation> | <operation> | <description>The stop lifecycle operation</description> | <name>stop</name> | </operation> | </xmbean> | </mbean> | before the | <mbean | code="org.jboss.security.jacc.DelegatingPolicy" | ...... | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3901538#3901538 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3901538 |
|
From: <sco...@jb...> - 2005-10-17 14:53:52
|
You are missing the PolicyName setting which allows the SecurityService to install a preconfigured instance: | <mbean code="org.jboss.security.jacc.SecurityService" | name="jboss.security:service=JaccSecurityService" | xmbean-dd=""> | <xmbean> | <descriptors> | <injection id="MBeanServerType" setMethod="setMBeanServer" /> | <injection id="ObjectNameType" setMethod="setObjectName" /> | </descriptors> | <attribute access="read-write" getMethod="getPolicyName" setMethod="setPolicyName"> | <description>The policy provider MBean name</description> | <name>PolicyName</name> | <type>javax.management.ObjectName</type> | </attribute> | <attribute access="read-write" getMethod="getPolicyAttributeName" | setMethod="setPolicyAttributeName"> | <description>The Policy attribute name on the PolicyName MBean</description> | <name>PolicyAttributeName</name> | <type>java.lang.String</type> | </attribute> | <operation> | <name>start</name> | </operation> | <operation> | <name>stop</name> | </operation> | </xmbean> | <attribute name="PolicyName">jboss.security:service=JaccPolicyProvider</attribute> | <attribute name="PolicyAttributeName">PolicyProxy</attribute> | </mbean> | Without this a new DelegatingPolicy instance is created that has no external permissions. The SecurityService installs the PolicyAttributeName attribute value as java.security.Policy, and this is not an instanceof DelegatingPolicy. The permissions would need to be obtained from the jmx ExternalPermissionTypes attribute, not by casting the Policy. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3901545#3901545 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3901545 |
|
From: mholzner <do-...@jb...> - 2005-11-01 19:18:02
|
and just when you think it's all working .... I followed your advice , and everything seemed to work. Now I started to work on redeployment issues and discovered that things derail on re deployment. I investigated a bit more and here is what I found: 1) if the mbean descriptor entries are in the jboss?service.xml in the portal sar, everything works as expected: there is one DelegatingPolicy instance that was created by the DelegatinPolicy mbean entry, and it is available to all the right places. Policy.getPolicy() returns it, and the PolicyConfigurationFactory uses it as well the issue here is that when I redeploy the sar , the mbean entry for the Delegating policy creates a new instance, and now the Policy.getPolicy() returns the new instance, and the PolicyConfigurationFactory still has the old instance, hence the Policy.implies() fails since it checks against the wrong DelegatingPolicy instance 2) if I take the mbean descriptor entries out of the sar into a separate file that I place into the deploy folder (I tried security?service.xml and jboss?service.xml) then the security service's start() method gets called much later then in 1), or at least appears to be, and as a result the AbstractWebDeployer kicks in before the DelegatingPolicy mbean , and has already a DelegatingPolicy installed by the time the DelegatingPolicy mbean gets a chance (this instance of the DelegatingPolicy doesn't know of the external permissions since it was not created via the DelegatingPolicy mbean entry, but rather via the JBossPolicyConfigurationFactory's constructor). As a result of that, the Policy.implies() check fails since the policy doesn't consider the PortalObjectPermission as a jaccPermission and hence delegates to the J2SE Policy to do the check. here are the mbean entries: | <mbean | code="org.jboss.security.jacc.DelegatingPolicy" | name="jboss.security:service=JaccPolicyProvider" | xmbean-dd=""> | <xmbean> | <attribute access="read?only" getMethod="getPolicyProxy"> | <description>The java.security.Policy implementation</description> | <name>PolicyProxy</name> | <type>java.security.Policy</type> | </attribute> | <attribute access="read?write" getMethod="getExternalPermissionTypes" setMethod="setExternalPermissionTypes"> | <description>The types of non?javax.security.jacc permissions to validate against this policy</description> | <name>ExternalPermissionTypes</name> | <type>[Ljava.lang.Class;</type> | </attribute> | <operation> | <name>listContextPolicies</name> | <return-type>java.lang.String</return-type> | </operation> | </xmbean> | <attribute name="ExternalPermissionTypes">org.jboss.portal.core.security.jacc.PortalObjectPermission</attribute> | </mbean> | <mbean | code="org.jboss.security.jacc.SecurityService" | name="jboss.security:service=JaccSecurityService" | xmbean-dd=""> | <xmbean> | <descriptors> | <injection id="MBeanServerType" setMethod="setMBeanServer"/> | <injection id="ObjectNameType" setMethod="setObjectName"/> | </descriptors> | <attribute access="read-write" getMethod="getPolicyName" setMethod="setPolicyName"> | <description>The policy provider MBean name</description> | <name>PolicyName</name> | <type>javax.management.ObjectName</type> | </attribute> | <attribute access="read-write" getMethod="getPolicyAttributeName" | setMethod="setPolicyAttributeName"> | <description>The Policy attribute name on the PolicyName MBean</description> | <name>PolicyAttributeName</name> | <type>java.lang.String</type> | </attribute> | <operation> | <name>start</name> | </operation> | <operation> | <name>stop</name> | </operation> | </xmbean> | <attribute name="PolicyName">jboss.security:service=JaccPolicyProvider</attribute> | <attribute name="PolicyAttributeName">PolicyProxy</attribute> | </mbean> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3904701#3904701 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3904701 |
|
From: mholzner <do-...@jb...> - 2005-11-01 19:21:02
|
and one more thing that I noticed:
the constructor of the JBossPolicyConfigurationFactory does the following check:
| Policy p = Policy.getPolicy();
| if( (p instanceof DelegatingPolicy) == false )
| {
| // Assume that the installed policy delegates to the DelegatingPolicy
| p = DelegatingPolicy.getInstance();
| }
| policy = (DelegatingPolicy) p;
|
If the installed Policy is infact an instance of the DelegatingPolicy, then what gets returned from the Policy.getPolicy() is never a DelegatingPolicy instance, but rather a DelegatingPolicy$PolicyProxy
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3904703#3904703
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3904703
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X