[JBoss JIRA] (AS7-5085) Operations to read content from the content repository
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-5085?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-5085:
----------------------------------
Fix Version/s: 8.0.0.Alpha1
(was: 7.3.0.Alpha1)
> Operations to read content from the content repository
> ------------------------------------------------------
>
> Key: AS7-5085
> URL: https://issues.jboss.org/browse/AS7-5085
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Priority: Minor
> Fix For: 8.0.0.Alpha1
>
>
> Ability to pull data out of the content repository. We can do that with rollout plans, but not for deployments or if we add deployment content overlays.
> Basically, if the user loses the original of the deployment, let's let them get it back via the management API and remove the temptation for them to hack into the repository.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-4997) Add reference description information to resource metadata
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-4997?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-4997:
----------------------------------
Fix Version/s: 8.0.0.Alpha1
(was: 7.3.0.Alpha1)
> Add reference description information to resource metadata
> ----------------------------------------------------------
>
> Key: AS7-4997
> URL: https://issues.jboss.org/browse/AS7-4997
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 8.0.0.Alpha1
>
>
> The AS's configuration model frequently includes attributes that are references to the name of some other resource in the model. The metadata describing such attributes must include information to help users and tooling to understand that reference.
> A simple approach would be to include a metadata attribute whose value is an absolute or relative path to the target resource.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-4998) Describe inheritance relationships in the resource description metadata
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-4998?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-4998:
----------------------------------
Fix Version/s: 8.0.0.Alpha1
(was: 7.3.0.Alpha1)
> Describe inheritance relationships in the resource description metadata
> -----------------------------------------------------------------------
>
> Key: AS7-4998
> URL: https://issues.jboss.org/browse/AS7-4998
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 8.0.0.Alpha1
>
>
> Some elements in the management model have an inheritance relationship with other elements located elsewhere. For example, system properties can be defined as a child of the root domain resource, as a child of a server-group resource, as a child of the root host resource, and as a child of the server-config resource.
> The resource description metadata for a resource needs to describe these relationships. It needs to cover the inheritance hierarchy, as well as how any conflicts are resolved (i.e. does the child win, as is the case with system properties and interfaces, or is some sort of merging strategy employed, as is the case with profiles and socket-binding-groups, where the sets of child resources (subsystems and socket-bindings) are merged, provided that the two sets are disjoint.
> A factor to include in this metadata is whether the relationship is fixed (i.e. host system-property inherits from server-group) or whether there is some attribute that defines the inheritance (e.g. a profile's that "includes" another profile has an attribute that defines the name of the included profile.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-4679) Catching custom login module exceptions in remote client
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-4679?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-4679:
----------------------------------
Fix Version/s: 8.0.0.Alpha1
(was: 7.3.0.Alpha1)
> Catching custom login module exceptions in remote client
> --------------------------------------------------------
>
> Key: AS7-4679
> URL: https://issues.jboss.org/browse/AS7-4679
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Remoting, Security, Server
> Affects Versions: 7.1.1.Final
> Environment: Win 7 64 Bit
> 4 GB RAM
> java 1.6
> Reporter: Serkan Yıldırım
> Assignee: Darran Lofthouse
> Labels: exception, login, login-module, remoting
> Fix For: 8.0.0.Alpha1
>
>
> This feature request is related with the discussion:
> https://community.jboss.org/message/732948#732948
> I have custom login modules in JBOSS 7.1.2 Snapshot. They are working with no error, i can authenticate and authorize a user. However, when an exception occurs at the time of login, i.e. wrong password, i throw javax.security.auth.login.LoginException with my custom message. But i couldn't catch the exception in the remote client. Darran said that it's not supported in this version. I think it is a necessary feature because a remote user could be informed why login is failed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-3112) Better integration of service based ServerAuthenticationProviders
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-3112?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-3112:
----------------------------------
Fix Version/s: 8.0.0.Alpha1
(was: 7.3.0.Alpha1)
> Better integration of service based ServerAuthenticationProviders
> -----------------------------------------------------------------
>
> Key: AS7-3112
> URL: https://issues.jboss.org/browse/AS7-3112
> Project: Application Server 7
> Issue Type: Task
> Components: Domain Management, Remoting, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: Remoting_Management
> Fix For: 8.0.0.Alpha1
>
>
> The security configuration of Remoting within AS7 is based on supplying three things: -
> - The ServerAuthenticationProvider to obtain mechanism specific CallbackHanlders
> - The OptionMap to control the security mechanisms made available / mandated.
> - Possibly an initialised SSLContext for XnioSsl if SSL is being enabled.
> For domain management the capabilities of the backing realm are used to define the security offered i.e. if we have no SSL configuration we can not enable SSL, if the backing store can not return the plain text passwords we can not enable DIGEST. This has been achieved so far by using an intermediary service to define the configuration based on capabilities alone.
> This task it to take it one step further and allow this intermediary to be defined within the Remoting subsystem and maybe an equivalent for pure domain management to act as both a intermediary to define configuration based on the realm and also to allow additional configuration overrides. i.e. we need to support the additional SASL options available and SSL options available - this will somehow need to be merged / validated with the realm capabilities e.g. if a Realm is incompatible with Digest a user can not force the use of Digest.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-6053) Reconsider post-boot logging of management operation errors
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6053?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-6053:
----------------------------------
Fix Version/s: 8.0.0.Alpha1
(was: 7.3.0.Alpha1)
> Reconsider post-boot logging of management operation errors
> -----------------------------------------------------------
>
> Key: AS7-6053
> URL: https://issues.jboss.org/browse/AS7-6053
> Project: Application Server 7
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 8.0.0.Alpha1
>
>
> Currently after boot if there is a failure during a management request we log it at DEBUG or not at all (see AS7-6046 for the not-at-all issue.) The theory is the error is a client request and the proper error reporting is to propagate the error to the client, which we do via the operation response.
> We need to consider logging some errors in the server log as well. Some errors can impact the state of the runtime services, and those kinds of errors should not be invisible in the log.
> A simple approach to this would be to log an ERROR message if the problem happened after Stage.MODEL. Any problems in Stage.MODEL never escape the data structures (i.e. the copy of the model) associated with the operation's OperationContext, and thus have no impact to anyone other than the caller.
> A further refinement to this would be to only report Stage.RUNTIME errors if the operation has taken an action implying mutation of the service container (context.getServiceRegistry(true) or context.removeService(...)).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-1519) Simple Domain Management Role Based Permissions
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-1519?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-1519:
----------------------------------
Fix Version/s: 8.0.0.Alpha1
(was: 7.3.0.Alpha1)
> Simple Domain Management Role Based Permissions
> -----------------------------------------------
>
> Key: AS7-1519
> URL: https://issues.jboss.org/browse/AS7-1519
> Project: Application Server 7
> Issue Type: Sub-task
> Components: Domain Management, Security
> Affects Versions: 7.0.0.Final
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: Authorization
> Fix For: 8.0.0.Alpha1
>
>
> Implement some coarse permissions for domain operations. Possibly allowing a break down for subsystem, profile, server, server-group - maybe read - write - execute.
> Also consider confidentiality in exchange e.g. Can read metrics over http but must use https to add new server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months