[JBoss Remoting Development] - SASL and Kerberos
by Darran Lofthouse
Darran Lofthouse [http://community.jboss.org/people/dlofthouse] modified the document:
"SASL and Kerberos"
To view the document, visit: http://community.jboss.org/docs/DOC-17302
--------------------------------------------------------------
Working on how Kerberos can be supported with Remoting for https://issues.jboss.org/browse/REM3-29 REM3-29, the first stage is understanding the unederlying mechanism.
*Please Note, this article is not a user guide, it is a reference guide to hold the information needed so that the issue REM3-129 can be implemented.*
Whilst there is some JDK documentation this does not go into the finer details, the implementation makes quite a few assumptions so this article is to capture the additional detail.
h1. Client
OS local Kerberos configuration can be used to specify the Ream and KDC, alternatively JVM wide system properties can be used: -
System.setProperty("java.security.krb5.kdc", "ec2-?-?-?-?.compute-1.amazonaws.com");
System.setProperty("java.security.krb5.realm", "DARRANL.JBOSS.ORG");
On the client side unless you fallback to default JAAS configurations the SASL negotiation needs to be within a PrivilegedAction where a Subject for the local clients identity is passed in: -
Subject.doAs(clientSubject, new PrivilegedAction<Void>() {
@Override
public Void run() {
try {
client.haveAChat();
} catch (IOException e) {
e.printStackTrace();
}
return null;
}
});
To obtain the subject a JAAS LoginContext is used with the 'com.sun.security.auth.module.Krb5LoginModule' LoginModule, although JAAS is used we don't need the configuration within a descriptor - we can provide a simplified configuration for the client and dynamically configure the LoginContext.
No special configuration of the LoginModule is required on the client side. There are three configuration options for the client: -
1. Use a supplied CallbackHandler to prompt the client for the username and password, the LoginModule will then obtain their Kerberos tickets.
2. Configure to use a keytab without prompting - useful for unattended processes e.g. server instances.
3. Configure to use local OS cache i.e. if user obtained Kerberos ticket on OS log on use this identity.
The client side does not require the 'storeKey' option being set to true although if a process is both a client and a server this can be set to true.
Inside the PriviledgedAction the SaslClient can be obtained as: -
Sasl.createSaslClient(MECHS, null, "remoting", "test2", Collections.EMPTY_MAP,
new NoCallbackHanlder());
The parameters are: -
1. Array of mechanisms, in this case just "GSSAPI"
2. The authorization ID, if not supplied it will default to the username@REALM of the user.
3. Protocol
4. Server host name
5. Configuration options
6. Callback Handler
*The values for protocol and server host name are criticial to the negotiation process.*
In this example before the communication with the server commences the client side will automatically send a TGS-REQ to the KDC for the server name 'remoting/test2' - this is an integral part of the process an if this server is not known by the KDC the process will terminate.
For this TGS-REQ a service principal mapping on the KDC is sufficient, however there are also issues on the server side of this to consider.
There are a couple of options which could be passed in, one is to enable server_auth, this setting means that in addition to the server verifying the identity of the client the client will also verify the identity of the server.
At the stage of the SASL message exchange the CallbackHandler on the client is not required to handle any callbacks, the client side idenity has already been established when the Subject was obtained.
If this was SPNEGO the web browser would be verifying the DNS name of the server it is connecting to, we should consider if our client should allow any flexibility in the setting of server host name or should we mandate that it does match the host name we are connecting to - at the same point also consider banning connection to IP addresses as DNS is also fundamental to this.
h1. Server
As for the client side the Realm / KDC configuration is required, again this can either be configured using OS specific configuration or the same system properties can be set.
On the server a Subject needs to be obtained similar to how one was obtained for the client, this time the Subject is for the identity of the server - all the Sasl calls will then be within a PriviledgedAction.
When the Subject for the server is obtained here it is essential that 'storeKey' is set to true for the LoginModule, this will store the KerberosKeys for the server in the PrivateCredentials of the Subject.
On the server side the SaslServer can be obtained with: -
SaslServer saslServer = Sasl.createSaslServer(GSSAPI, "remoting", "test2", Collections.EMPTY_MAP,
new AuthorizeCallbackHandler());
Here the parameters are: -
1. Chosen mechanism "GSSAPI"
2. Protocol
3. Server Host Name
4. Configuration options
5. Callback Handler
On the server side the protocol and server host name are again critical to the process but this time they affect how the PrivateCredentials of the Subject are searched.
In this example the protocol is 'remoting', the server host name is 'test2' and from the system properties the realm is 'DARRANL.JBOSS.ORG', the private credentials of the Subject will be searched for KerberosKeys with the prinicipal name " mailto:remoting/test2@DARRANL.JBOSS.ORG remoting/test2(a)DARRANL.JBOSS.ORG"
On the server side an error indicating "Mechanism level: Failed to find any Kerberos Key" most likely translates to mean that no key has been found with the expected principal name.
The server identity does need to match the identity the client received in the TGS-REP from the TGS-REQ that the client sent in, however I need to verify if the names within the Subject also need to match or if we can just allign the createSaslServer identity with what is provided in the Subject. The reason this needs to be considered is that it may be desirable to just have a single Kerberos identity on the server for both Remoting and HTTP, however for HTTP the identity may already be mapped to HTTP/test2
The only Callback that needs to be supported is the AuthorizeCallback, by default the authentication ID will be in the form username@REALM - there may be some desire to drop the @REALM part.
In the exchange between the client and the server we do need to be able to support 0 length SASL messages.
There is also an option that may be possible to set on the server side if the identity is only being used for incomming requests and that is to set isInitiator to false, this removes one round trip with the KDC.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-17302]
Create a new document in JBoss Remoting Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
12 years, 3 months
[JBoss AS 7 Development] - Re: JBoss Modules and a NICE Documentation
by Nikos Ballas
Nikos Ballas [http://community.jboss.org/people/cirix] created the discussion
"Re: JBoss Modules and a NICE Documentation"
To view the discussion, visit: http://community.jboss.org/message/644355#644355
--------------------------------------------------------------
@Stephen and here is the proof: https://issues.jboss.org/browse/AS7-1769 https://issues.jboss.org/browse/AS7-1769
@jaikiran:The point is the following.I would like to have a modular architecture.Imagine i have everything in non exploded ear and my ejb-jar file exposes
some services to external clients.Now the scenario is i want to update the .war file for adding some new pages.Thus i would have down time for the services which should be working cause we are using what is called N-TIER architecture and for me that's the correct behaviour of an application that
utilizes that type of architecture.Bundling everything up in an ear for my point of view isn't n-tier architecture in practice.Having different layers should imply that also from top down when you are making changes the change in a higher layer should reflect changes in the lower application layer.I was
hoping that the module environment offered by jboss would be exactly that answer.This was more or less happening in the previous way of loading as
long as the core dependency wasn't remove and that should always be the case.I mean if someone decides to bring down the persistence layer then no other service should be available if we are discussing for db driven apps, such then one i am on.I am aware of the jsr...but i think also you can inject in subdeployment in jboss by specifing the isolated subdeployments in the ee subsystem or in the jboss-deployement-structure file of the ear.But still from
my description simply i think the correct technology to use is OSGi.I was hopping from what i was reading that JBoss Module would provide more or less the same layer of functionality but...far from being true :) .
regards
\n\m
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/644355#644355]
Start a new discussion in JBoss AS 7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 3 months
[JBoss AS 7 Development] - Remote EJB Client with SASL and Kerberos Authentication fails on jboss-as-7.1.0.Final-SNAPSHOT ( 02.02.2012)
by Radek Rodak
Radek Rodak [http://community.jboss.org/people/rodakr] created the discussion
"Remote EJB Client with SASL and Kerberos Authentication fails on jboss-as-7.1.0.Final-SNAPSHOT ( 02.02.2012)"
To view the discussion, visit: http://community.jboss.org/message/644350#644350
--------------------------------------------------------------
Hi
I tried to use SASL and GSSAPI for Authentication on jboss-as-7.1.0.Final-SNAPSHOT but it fails...
I did what is wroten here: http://community.jboss.org/docs/DOC-17302 http://community.jboss.org/wiki/SASLAndKerberos
Client Code is able to execute createSaslClient in Privileged Action after successfull KRB5 Jaas Login:
Sasl.createSaslClient(new String[]{"GSSAPI"}, null, "remoting", "test2", Collections.EMPTY_MAP, new NamePasswordCallbackHandler2("someuser","somepass" ) );
, but it fails with this Exception... :
[java] Client Addresses Null
[java] Initial Context created
[java] lookupejb:/sl-securityTestEjb3//TestServiceSLEJB3Bean!ch.swisslife.test.ejb3.TestServiceItf @RolesAllowed({"BackofficeRole"})
[java] 03.01.2012 13:54:35 org.jboss.ejb.client.EJBClient <clinit>
[java] INFO: JBoss EJB Client version 1.0.0.Beta11
[java] lookup testEjbJndi successful
[java] call unsecured Method permittAllMethod()
[java] 03.01.2012 13:54:36 org.xnio.Xnio <clinit>
[java] INFO: XNIO Version 3.0.0.GA
[java] 03.01.2012 13:54:36 org.xnio.nio.NioXnio <clinit>
[java] INFO: XNIO NIO Implementation Version 3.0.0.GA
[java] 03.01.2012 13:54:36 org.jboss.remoting3.EndpointImpl <clinit>
[java] INFO: JBoss Remoting version 3.2.0.CR8
[java] 03.01.2012 13:54:36 org.jboss.remoting3.remote.RemoteConnection handleException
[java] ERROR: JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
[java] 03.01.2012 13:54:36 org.jboss.ejb.client.ConfigBasedEJBClientContextSelector createConnections
[java] ERROR: Could not create connection for connection named default
[java] java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
[java] at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
[java] at org.jboss.ejb.client.ConfigBasedEJBClientContextSelector.createConnection(ConfigBasedEJBClientContextSelector.java:292)
[java] at org.jboss.ejb.client.ConfigBasedEJBClientContextSelector.createConnections(ConfigBasedEJBClientContextSelector.java:209)
[java] at org.jboss.ejb.client.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:138)
[java] at org.jboss.ejb.client.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:120)
[java] at org.jboss.ejb.client.ConfigBasedEJBClientContextSelector.<clinit>(ConfigBasedEJBClientContextSelector.java:110)
[java] at org.jboss.ejb.client.EJBClientContext.<clinit>(EJBClientContext.java:57)
[java] at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:91)
[java] at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:83)
[java] at $Proxy0.permittAllMethod(Unknown Source)
[java] at ch.swisslife.client.krb5.GetAction.run(TestServiceClient.java:154)
[java] at ch.swisslife.client.krb5.GetAction.run(TestServiceClient.java:114)
[java] at java.security.AccessController.doPrivileged(Native Method)
[java] at javax.security.auth.Subject.doAs(Subject.java:396)
[java] at TestServiceKrb5Client.main(TestServiceClient.java:76)
[java] Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
[java] at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:358)
[java] at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:207)
[java] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
[java] at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
[java] at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
[java] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
[java] at org.xnio.nio.NioHandle.run(NioHandle.java:90)
[java] at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
[java] at ...asynchronous invocation...(Unknown Source)
[java] at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:268)
[java] at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:250)
[java] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:359)
[java] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:343)
[java] at org.jboss.ejb.client.ConfigBasedEJBClientContextSelector.createConnection(ConfigBasedEJBClientContextSelector.java:290)
[java] ... 13 more
[java] 03.01.2012 13:54:36 org.jboss.ejb.client.ConfigBasedEJBClientContextSelector createConnections
[java] INFO: Connection default will not be available in EJB client context org.jboss.ejb.client.EJBClientContext@e2dae9
[java] java.lang.IllegalStateException: No EJB receiver available for handling [appName:,modulename:sl-securityTestEjb3,distinctname:] combination
[java] at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:344)
[java] at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:92)
[java] at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:83)
[java] at $Proxy0.permittAllMethod(Unknown Source)
[java] at ch.swisslife.client.krb5.GetAction.run(TestServiceClient.java:154)
[java] at ch.swisslife.client.krb5.GetAction.run(TestServiceClient.java:114)
[java] at java.security.AccessController.doPrivileged(Native Method)
[java] at javax.security.auth.Subject.doAs(Subject.java:396)
[java] at ch.swisslife.client.krb5.TestServiceClient.main(TestServiceClient.java:76)
I tried using those client jars:
jboss-ejb-api_3.1_spec-1.0.1.Final.jar
jboss-ejb-client-1.0.0.Beta11.jar
jboss-jacc-api_1.4_spec-1.0.1.Final.jar
jboss-logging-3.1.0.CR2.jar
jboss-marshalling-1.3.4.GA.jar
jboss-marshalling-river-1.3.4.GA.jar
jboss-remoting-3.2.0.CR8.jar
jboss-sasl-1.0.0.Beta9.jar
jboss-transaction-api_1.1_spec-1.0.0.Final.jar
xnio-api-3.0.0.GA.jar
xnio-nio-3.0.0.GA.jar
Some hints what's wrong... or is this not yet supported?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/644350#644350]
Start a new discussion in JBoss AS 7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 3 months
[JBoss AS 7 Development] - JBoss Modules and a NICE Documentation
by Nikos Ballas
Nikos Ballas [http://community.jboss.org/people/cirix] created the discussion
"JBoss Modules and a NICE Documentation"
To view the discussion, visit: http://community.jboss.org/message/644060#644060
--------------------------------------------------------------
Dear all,
trying to develop in the new jboss 7, i can undestand that is a nice playground to test new things BUT is far from being an appserver to be use for
developing production critical systems. The only reason for it for me is clear and that's why i will probably will go back to JBoss 6.
THERE IS NO DESCENT DOCUMENTATION. Is clear for me when i have to choose, i would go for something that isn't cutting edge but is well documented, rather than something that is promised to be good but has no real documentation.We all know that coding is one thing but documentation something totally different and i think there was the success of the jboss appserver until now.The documentation was verbose and complete, whereas with the new version the team decided not to give the top QA it used to give on documenting the new appserver
.When i have a question on my head at the end the solution is to get from Git the sources and debug.BUT that's not productive.I want to focus on developing my application and not trying to discover how the app server works by reading the entire source tree.For me the biggest burden for example currently is that we all read about the jboss module architecture that will bring revolution to the way we deploy and handle applications.But tell me why i shouldn't choose over the OSGi that is REALLY WELL DOCUMENTED and has proven it's value.No after some <flame-mode>on</flame-mode>.
I need a clear answer where i can find documentation for implementing the following using jboss modules(links like classloading how to and jboss modules AREN'T accepted as valid BECAUSE THERE IS NO VALUABLE INFORMATION ON THEM.):
Module1: contains persistence.xml and the entity classses..
Module2: conatains the EJB's for the business layer and MUST be able to use the Module1.So there is a dependency from Module2->Module1.
Module3: contains the .war which will be the interface and is clear that :Module3->Module2->Module1 and Module3->Module1.
I have created the com/test/module1/main com/test/module2/main and the resulting module.xml file respectively.But I DON'T SEE the modules
to be loaded.Trying to figure out how the classloadin will take place i am more confused than cleared.
The documentation of JBoss Module can only be characterised the lease deficient.
At the end i think i will either choose to go back to JBoss6 or go with the OSGi solution which i know how to do things.
at your disposal for any clarification.
best regards
\n\m
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/644060#644060]
Start a new discussion in JBoss AS 7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 3 months
[JBoss AS7 Development] - Re: Weld-OSGi integration in AS7
by Kevin Pollet
Kevin Pollet [http://community.jboss.org/people/kevinpollet] created the discussion
"Re: Weld-OSGi integration in AS7"
To view the discussion, visit: http://community.jboss.org/message/605472#605472
--------------------------------------------------------------
> Thoughts?
Hi all,
I just want to give you my thinking and Mathieu's thinking about the use of the OSGiService qualifier. First of all, we agree with you that it's possible to get rid of the OSGiService qualifier (if a service is not found in CDI, it's possible to look at the OSGi service registry).
I thought a lot about this and one interrogation comes to my mind. How differentiate the case of a missing CDI binding and the case of a local implementation for a service? The default behavior of CDI is to throw an exception specifying that there is no binding for this injection target but in this case, a proxy waiting for an hypothetical OSGi service will be injected (and obviously will fail at runtime). IMHO, doing this will break the default CDI programming model. I mean that the user applicition will start without any problem in our case but in the default CDI programming model an exception will be thrown. We think that the user have to specify where he wants to use OSGi (so the user will knows where to deal with OSGi dynamism).
On the other hand, as you say in your above comments, this feature has to be enabled by the user. In this case he could be aware of this behavior, but we think it's too much changes for the CDI programming model.
WDYT?
Kevin & Mathieu
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/605472#605472]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 3 months