[JBoss AS 7 Development] - Authentication Service
by Darran Lofthouse
Darran Lofthouse [https://community.jboss.org/people/dlofthouse] modified the document:
"Authentication Service"
To view the document, visit: https://community.jboss.org/docs/DOC-47997
--------------------------------------------------------------
h1. Authentication Service
This article is do describe the new authentication service being added to AS7 to support security context proagation and connection re-authentication. Until the component is complete this article should be considered work in progress.
Due to the dependencies involved this service is developed as a stand alone project that will be subsequently integrated into the application server, most likely the security subsystem.
h3. Project Structure
The project (will) provide(s) the following: -
h4. Authentication Service
This is the core service running within the application server, this service is associated with all supported security realms and handles the authentication requests and the providing of the authenticated identities internally.
h4. Server API
Fer secured services looking to use the identities an API will be provided for direct access to the service. A permissions check on the SecurityManager (if any) will be performed to verify the call should be allowed, user code must not be able to interact with the service unless that permission is granted.
The server API may also provide an API that can be mapped to domain management operations to allow the state of the authentication service and the connection to be managed.
h4. Internal Client API
On the client side calls will be made to the remote authentication service using the defined protocol over Remoting - to simplify the use of the protocol this will be wrapped by an API - however this is most likely not the API that the clients will use to manage the associated identities.
h4. Public Client API
This is the API that will be used by client applications to manipulate the identities associated with the current connection, use cases are being identified and the resulting API will be to solve those use cases.
h4. Versioned Remoting Protocol
The protocol itself will live in it's own module, client and server side of the protocol will be written in parallel to ensure they remain in synch.
h3. Remoting Protocol
The protocol is a versioned protocol, this means that the client and server will negotiate to use the most up to date protocol that both sides understand. The only exception to this is that both sides will also allow for versions to be excluded either through configuration, their APIs or by system properties - the reason for this is that if a vulnerability or bug is found in a version of the protocol it can be excluded - this is applicable even for older versions as you may not want a client to force the use of an older version with a known issue.
The versioning will also indicate if the protocol version is from a Final release or an intermediate release, backwards compatibility is only maintained within a protocol once it has reached the final state.
h3. Application Server Integration
h4. Configuration
Items to be configured within the application server: -
The service itself is a generic service, initially this is being used for EJB invocations however this can potentially be used for all services so the configuration of the service needs to be central - I would suggest within the security subsystem.
The service will only be installed if the configuration is present.
* Available Realms
* Advertise Realms? Should clients be able to request a list of available realms.
* SASL Configuration - the capabilities of the realms guide this but additional overrides may be needed.
* Caching configuration - validity periods? limit per connection?
h4. EJB Container
The EJB container will need to be modified so that if a request is received with a token ID then the Server API should be used to obtain that identity and run the request as that identity.
Where a call is being made to a remote server there needs to be some form of switch to enable propagating the identity to the remote server, this most likely needs an API option and a configuration option to enable it.
h4. EJB Clients
The EJB client side in conjunction with the public client API will need to support the client side management and switching of identities and the passing of the selected token with the method invocation.
h4. Security Realms
The security realms now need to be updated as to support this feature a user authenticating to the server needs to be able request an alternative id for the authorization decisions.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-47997]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
10 years, 9 months
[JBoss Tools Development] - Developing for JBoss Tools
by Rob Stryker
Rob Stryker [https://community.jboss.org/people/rob.stryker] modified the document:
"Developing for JBoss Tools"
To view the document, visit: https://community.jboss.org/docs/DOC-21381
--------------------------------------------------------------
JBoss Tools is a large conglomerate of plugins and components from many different locations. This page will help committers and hackers navigate the process of setting up a development environment, contribute patches, and navigate any approval processes required.
*Development Environment*
The first thing any developers will want to know is https://community.jboss.org/docs/DOC-18124 How to set up your development environment. This involves choosing which eclipse you'll want to install, your choices of java, subversion, eclipse target platform, which parts of the svn tree to checkout, and how to run tests from inside your IDE.
*Building JBoss Tools
*
Not all contributors will want to go through the trouble, but, if you really want to make sure your changes work the same in PDE's runtime environment (inside eclipse) as they do from a tycho build, which is the build system we use, you'll also want to try to build your project via the command line. You'll be able to set up your first builds by reading How to build JBoss Tools with Maven 3 (https://community.jboss.org/docs/DOC-16604). All committers are expected to build their component locally and verify the tests still pass before committing any major patches.
Sometimes, running your test suite in PDE vs in Tycho (command line build) have different results in the test suite. This is unfortunate, but it *does* happen. If you're getting inconsistant results, and really need to figure out what's going wrong, you'll want to read about https://community.jboss.org/docs/DOC-15209 Using Eclipse for Remote Debugging Tycho Build.
*Submitting / Committing patches*
All commits should reference a jira. All committers are required to have a jira target in every svn commit message. This helps keep our history easy to trace back through when searching for regressions. This helps keep us aware of what use cases caused the regression, and what to look out for and re-test when reverting or re-fixing an issue. Without a jira reference, if "fixing" one regression might create a new one, we'll have no way to find out why the change was committed in the first place, or what the change thought it was fixing.
In general, the process for submitting / committing a patch is:
1) Open a jira describing the bug
2) Attach the patch to the jira.
3) If you are a core developer,
a) simply commit the patch. Otherwise,
b) assign the issue to the component lead asking for approval and assistence in committing.
4) Resolve the issue as "done". Make sure to target the fix version accurately.
Try to make sure your description, or at least a closing comment, reference exactly how to replicate the issue, so that QE can verify that the issue is fixed. This also helps maintain the integrity of our code.
*What happens after a commit?*
For those very curious contributors, core developers, or testers, This Image (/servlet/JiveServlet/downloadImage/102-18462-4-18759/HowWeBuild_Diagram.png) shows what happens in our infrastructure upon a commit. In short, a hudson jobs get kicked off to build the component, and rebuild any components that depend on it, and push all changes to update sites. You can get a good look at what update sites are used and where over at this (https://community.jboss.org/docs/DOC-18462) article. Knowing what update site to use is very useful for anyone using bleeding-edge nightly builds.
*Documentation*
Committers and component owners are expected to keep their documentation up to date.They will also need to learn how to https://community.jboss.org/docs/DOC-13341 Build their Documentation.
*Other development tasks*
Working with branches is also a bit complicated, since our build system may (depending on the flags used) install items into your maven repository. The Working with Branches (https://community.jboss.org/docs/DOC-17497) article will be very helpful here.
*
*
There are other more complicated development tasks that require much more approvals than a simple commit. Creating or removing top-level components from our svn tree have processes associated with them (or will soon ;) ). Moving plugins, tests, or features between components also require such approvals.
*
*
1) Adding a new top-level component: Approval Process and Technical Process (TODO)
2) Adding a plugin, feature, or test, to a component: Approval Processt (https://community.jboss.org/docs/DOC-21382) and Technical Process (https://community.jboss.org/docs/DOC-18373) (TODO)
3) Deleting a plugin, feature, or test, from a component: Approval Process and Technical Process (TODO)
4) Deleting a top-level component: Approval Proces and Technical Process (TODO)
5) Moving a plugin, feature, or test, from one component to another: Approval Process and Technical Process (TODO)
6) Adding a different component as a dependency to your component. Approval Process and Technical Process (TODO)
7) Addition of external dependencies requiring an adjustment to target platform: Approval Process and Technical Process (TODO)
Some of these tasks may not seem complicated, but, they still require wide distribution and notification on the proper mailing lists, and in some cases, followup jiras to the build team. While adding a component as a dependency to your plugin might seem simple, it has the potential to cause circular dependencies, or simply cause extra builds and waste resources. Often, the build team needs to be alerted to these changes to adjust their cascading builds scripts and properly position your jobs where they belong.
*Maintenance and Rampdown procedures*
*
*
Maintenance releases typically contain only bug-fixes, with no additional features. While there is no official process declared yet, in general, maintenance patches require approval from PM or at the very least another committer on the same component. During rampdown for a major release, such as during candidate releases, similar restrictions are in place. Look here for more information in the future.
During maintenance releases, all forms of api breakage are forbidden. While there is often debate as to what exactly constitutes an api breakage, this http://wiki.eclipse.org/Evolving_Java-based_APIs_2 eclipse document can help identify what constitutes api breakages and what doesn't. One thing to be aware of is that adding a public or protected method or field to any class that may subclassed DOES constitute a breakage. In theory, a subclass may have a method or field of the same name or signature. However the risk for these situations will be evaluated separately and may still be allowed into maintenance if the risk is low.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-21381]
Create a new document in JBoss Tools Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
10 years, 9 months