[Beginners Corner] - Re: jBPM + WebServices + EJB 3.0
by cdc08x
Hi Francesco (and who reads here)!
I searched and read and searched again, after reading your very useful links, and my problem remained the same: WebService in EJB 3.0 must be deployed over StateLESS Session Beans, then there is no way to mantain the state of the current process running - apart from explicitly pass it through the methods' parameters.
For example, if I want the user to select a product @WebMethod public void selectProduct(Product p) before adding it to cart @WebMethod addToCart(Product p), this rule is easily expressible on a process. But how may I connect the transition of the process instance to the WS calls?
Then, it seems that Seam works best (with conversation ids and so on), to my purpose - more than the jBPM / jPDL suite for JBossAS.
Am I wrong? If so, tell me (any link with examples or whatever should be very appreciated! :)
Thanks in advance!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4174539#4174539
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4174539
17 years, 10 months
[Security & JAAS/JBoss] - Re: SSO on JBOSS with Kerberos
by noFreak
ok, is there even a way to sent a pm :)?...
Dann kopiere ich das wesentliche mal hier rein, sorry für die formatierung, allerdings ist mir das jetzt zu viel arbeit, das alles ordentlcih aussehen zu lassen :)
Single Sign-On Umsetzung mit Kerberos
Nachdem wir alle benÃÂötigten Technologien kennen gelernt haben, werden wir uns in diesem Kapitel der Umsetzung einer SSO Komponente in Java mithilfe von Kerberos widmen. Da die Konkrete Implementierung in einem Beispielprojekt im Anhang vorhanden ist, mÃÂöchten wir hier lediglich auf die Umzusetzende FunktionalitÃÂät und der Zuordnung zu den verschiedenen Technologien eingehen. Dabei soll klar werden, wie die Technologien miteinander agieren und in welcher Reihenfolge dies geschieht.
ZunÃÂächst sollten wir uns noch einmal die Vorgehensweise der Authentifizierung wie zu Beginn beschrieben genauer anschauen. Dabei unterteilen wir die Schritte in Client und Serverseitige Aufgaben.
Client:
1.Der Benutzer meldet sich an seinem Betriebssystem mit einem DomÃÂänenkonto an. Dabei wird mithilfe von Kerberos ein sicherer Kontext auf dem Client des Benutzers hergestellt. Bei diesem Schritt werden zwischen dem Betriebssystem und dem AS von Kerberos die beiden Nachrichten Authentication Server Request und Authentication Server Reply ausgetauscht. Innerhalb eines sicheren Bereichs des Arbeitsspeichers wird das TGT gespeichert. SchlÃÂüsselkomponente : Kerberos
2.Die Anmeldung an dem Betriebssystem ist vollstÃÂändig.
3.Der ORGA Benutzer startet auf diesem Client eine auf ORGA basierende Anwendung. Das TGT wird aus dem Arbeitsspeichers ausgelesen. Das LoginModule Krb5LoginModule von JAAS ÃÂübernimmt diesen Schritt.
4.Das ORGA Modul fordert mit dem TGT ein Service Ticket fÃÂür den Dienst, welcher AusgefÃÂührt werden soll. Dieses Service Ticket kann ausschlieÃÂÃÂlich fÃÂür diesen Dienst genutzt werden. Das senden des TGT wird durch Kerberos innerhalb der Nachricht Ticket Granting Server Request abgebildet und mit dem Java GSS-API transparent implementiert. SchlÃÂüsselkomponenten: Kerberos und Java GSS-API
5.Der angeforderte SchlÃÂüssel wird dem Client ausgeliefert. Das ausliefern wird durch die Kerberos Nachricht Ticket Granting Server Reply durchgefÃÂührt wobei das Empfangen auf der Seite des Clients mithilfe von Java GSS-API abstrakt implementiert wird. SchlÃÂüsselkomponenten: Kerberos und Java GSS-API
6.Das Service Ticket wird Base64 kodiert und mithilfe von JBoss FunktionalitÃÂäten an diesen gesendet. Dieser Schritt entspricht dem Application Request in der Kerberos Authentifizierung, wird allerdings nicht von Kerberos oder dem Java GSS-API durchgefÃÂührt. SchlÃÂüsselkomponente: JBoss
Server:
7.Der JBoss empfÃÂängt das Service Ticket und decodiert es. Danach wird transparent durch Java GSS-API geprÃÂüft ob es von einem sicheren Client ist und ob er den angeforderten Dienst ausfÃÂühren darf. SchlÃÂüsselkomponente: Java GSS-API und Kerberos
Um diese FunktionalitÃÂäten Umzusetzen implementieren wir zwei LoginModule. Eines Clientseitig fÃÂür die Schritte 3 bis 6 und eines Serverseitig fÃÂür den Schritt 7. Lesen Sie sich zum besseren VerstÃÂändnis der Vorgehensweise am besten die jeweiligen Codeabschnitte im Projekt mgs-orga-security durch.
Clientseitige Umsetzung:
Das Clientseitige LoginModule benennen wir mit KerberosClientLoginModule. Es setzt sich folgendermaÃÂÃÂen zusammen:
Es hat als member das Krb5LoginModule um das TGT anfordern zu kÃÂönnen.
initialize(...):
Diese Methode sorgt fÃÂür die Initialisierung des Login Modules. Die Werte der Optionen krbRealm, kdcAddress und serviceName werden ausgelesen, Membervariablen der Klasse zugewiesen und teilweise als Systemeigenschaft gesetzt. Dies ist nÃÂötig, damit spÃÂäter die Java GSS-API darauf zugreifen kann. AuÃÂÃÂerdem wird ein neues Krb5LoginModule instantiiert und ebenfalls dessen initialize Methode aufgerufen.
abort():
Hier setzen wir alle Membervariablen auf null. AuÃÂÃÂerdem rufen wir die abort() Methode des Krb5LoginModule auf.
commit():
Da wie spÃÂäter in Abschnitt der Methode login() bereits alle nÃÂötigen Informationen gespeichert wurden, ist hier nichts mehr zu tun.
logout():
Wie bei der Methode abort() setzen wir alle Membervariablen auf null und rufen die logout Methode des Krb5LoginModule auf.
login():
Die Aufwendigste aller Methoden.
ZunÃÂächst wird versucht ein Login mithilfe des Krb5LoginModule durchzufÃÂühren. Dabei wird das TGT aus dem Betriebssystem ausgelesen. Ist dies nicht erfolgreich, wird je nach Konfiguration des LoginModule's mÃÂöglicherweise das Passwort und der Benutzername vom Benutzer erfragt und versucht anhand deren ein TGT vom KDC zu beziehen. Ist der Loginvorgang des Krb5LoginModule erfolgreich werden mit der Methode commit die Credentials (also auch das TGT) und die Principals in das bei der Initialisierung ÃÂübergebene Subject geschrieben. Dies bereitet uns die Grundlage um ein Service Ticket zu erhalten.
Im nÃÂächsten Schritt wird eine PrivilegedAction im Namen des Subjects ausgefÃÂührt. Dabei wird wie im Kapitel 3.6 Java Generic Security Service API (Java GSS-API) beschrieben zuerst anhand des TGT's das Service Ticket vom KDC angefordert. Wurde dieses zurÃÂückgeliefert wird es Base64 codiert und zur ÃÂÃÂbertragung an den JBoss beim einem Aufruf einer EJB aufbereitet.
Wird dabei keine Rezeption geworfen und wird beim Anfordern des Service Tickets ein sicherer Kontext erstellte, so kann man davon ausgehen, dass der Benutzer am JBoss authentifiziert werden kann. Der Clientseitige Vorgang ist damit abgeschlossen.
Achtung!: Eine Authentifizierung des Clients am Server ist noch nicht sichergestellt. Der JBoss kann immer noch die IdentitÃÂät des Subjects ablehnen! Dies kann bisher nicht festgestellt werden, da die Serverseitige Authentifizierung erst bei Aufruf einer EJB vonstatten geht.
Serverseitige Umsetzung:
Wie wir bereits im Kapitel 3.4.3.1 Unterschied zum Standard JAAS LoginModule gelernt haben, mÃÂüssen wir hier anders wie bei einem normalen LoginModule von der Abstrakten Klasse AbstractServerLoginModule erben und somit auch andere Methoden implementieren. Unserer Klasse nennen wir KerberosJBossLoginModule. Da wir fÃÂür den vom Server bereitgestellten Service ebenfalls ein TGT benÃÂötigen, verwenden wir hier wie beim Clientseitigen LoginModule ebenfalls das Krb5LoginModule als Member unserer Klasse.
initialize(...):
Wie beim Client benÃÂötigen wir ebenfalls die Optionen krbRealm und kdcAddress. Diese werden wieder als Systemeigenschaft gesetzt, damit die Java GSS-API sie verwenden kann. AuÃÂÃÂerdem haben wir noch die Optionen name und password, mit deren Werte wir spÃÂäter das TGT fÃÂür den Dienst erhalten kÃÂönnen.
Weiterhin initialisieren wir das Krb5LoginModule, allerdings mit einem selbst geschriebenem CallbackHandler welcher das eben genannte Passwort und den Name als Konstruktorparameter hat. Dieser CallbackHandler wird spÃÂäter dem Krb5LoginModule die nÃÂötigen Daten (Passwort und Name) liefern, welche zur Anforderung des TGT's nÃÂötig sind. Eine weitere AuffÃÂälligkeit ist, dass wir hier dem Krb5LoginModule nicht das zur Initialisierung ÃÂübergebene sondern ein selbst erstelltes subject bei der Initialisierung ÃÂübergeben. Dies ist daran zu BegrÃÂünden, dass das ÃÂübergebene Subject nach dem Login dazu verwendet wird, den Aufrufenden Benutzer zu identifizieren. Da wir zum Anfordern des TGT's aber auch ein Subject benÃÂötigen, verwenden wir hier eines, welchen den Server reprÃÂäsentiert.
getIdentity():
Mit dieser Methode fragt der Server nach der IdentitÃÂät des Aufrufenden Subjects. Wir geben als ein Principal des Subjects zurÃÂück.
getRoleSets():
Da dieses LoginModule ausschlieÃÂÃÂlich zur Authentifizierung des Benutzers dienen soll, ÃÂübergeben wir hier lediglich ein Objekt, welches angibt, dass dem Subject bisher keine Rollen zugeteilt wurden.
login():
Als erstes wird ein TGT vom KDC angefordert. Dies wird benÃÂötigt, um das vom Client gesendete Service Ticket zu validieren und die AuthentizitÃÂät des innerhalb des Service Tickets angegebenen aufrufenden Clients zu prÃÂüfen. Da das zustÃÂändige Krb5LoginModule mit dem selbst geschriebenen CallbackHandler initialisiert wurde, werden hierbei die in den Optionen angegebene Werte des Passwortes und Namens herangezogen.
Wenn dieser Vorgang erfolgreich war, wird im Namen des Servers wieder eine PrivilegedAction ausgefÃÂührt. Innerhalb dieser wird das vom Client ÃÂübertragene Service Ticket Base64 decodiert und geprÃÂüft ob es von einem gÃÂültigen Client stammt und ob dieser Authentifiziert werden darf. Wenn dem so ist, wird das Subject zur weiteren Verwendung aufbereitet wesentliche Daten in den sharedState der LoginModule geschrieben. Der Serverseitige Authentifizierungsvorgang ist somit abgeschlossen.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4174537#4174537
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4174537
17 years, 10 months
[JBoss Messaging] - Problem while publishing message to the Queue
by tpawankumar
Hi All,
I am publishing the message to the Queue but second time when i publish the same message it is giving me the following exception
| 15:23:22,184 ERROR [ClosedInterceptor] ClosedInterceptor.ClientSessionDelegate[7
| ]: method createObjectMessage() did not go through, the interceptor is CLOSED
| 15:23:22,184 ERROR [STDERR] javax.jms.IllegalStateException: The object is close
| d
| 15:23:22,184 ERROR [STDERR] at org.jboss.jms.client.container.ClosedIntercep
| tor.invoke(ClosedInterceptor.java:157)
| 15:23:22,184 ERROR [STDERR] at org.jboss.aop.advice.PerInstanceInterceptor.i
| nvoke(PerInstanceInterceptor.java:105)
| 15:23:22,184 ERROR [STDERR] at org.jboss.jms.client.delegate.ClientSessionDe
| legate$createObjectMessage_5541516037526997237.invokeNext(ClientSessionDelegate$
| createObjectMessage_5541516037526997237.java)
| 15:23:22,184 ERROR [STDERR] at org.jboss.jms.client.delegate.ClientSessionDe
| legate.createObjectMessage(ClientSessionDelegate.java)
| 15:23:22,184 ERROR [STDERR] at org.jboss.jms.client.JBossSession.createObjec
| tMessage(JBossSession.java:134)
| 15:23:22,184 ERROR [STDERR] at com.covad.emailmgrservice.helper.VitriaUtil.e
| mailTriggered(VitriaUtil.java:259)
| 15:23:22,184 ERROR [STDERR] at com.covad.emailmgrservice.ejb.bean.EmailMgrBe
| an.sendEmail(EmailMgrBean.java:222)
| 15:23:22,184 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(
| Native Method)
| 15:23:22,184 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(N
| ativeMethodAccessorImpl.java:39)
| 15:23:22,184 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invo
| ke(DelegatingMethodAccessorImpl.java:25)
| 15:23:22,184 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:5
| 85)
Following is my sender class
| public class JmsUtil {
|
| private static InitialContext context=null;
| private static QueueSession session=null;
| private static QueueConnection conn=null;
|
|
| static {
|
| initVitria();
|
| }
|
|
|
| private static void initVitria() {
|
| try {
|
|
| Properties prop=new Properties();
| prop.setProperty(Constants.INITIAL_FACTORY, Constants.INITIAL_FACTORY_VALUE);
| prop.setProperty(Constants.URL_PACKAGE, Constants.URL_PACKAGE_VALUE);
| prop.setProperty(Constants.URL_PROVIDER,Constants.URL_PROVIDER_VALUE);
|
| context =new InitialContext(prop);
|
| QueueConnectionFactory connectionFactory=(QueueConnectionFactory)context.lookup("ConnectionFactory");
| conn=connectionFactory.createQueueConnection();
| session=conn.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
|
| conn.start();
|
| } catch (Exception e) {
|
| e.printStackTrace();
|
| }
|
| }
|
|
|
|
|
| public static void emailTriggered(String emailType, Map emailAttributes)
|
| throws Exception {
|
|
|
| Vector list = new Vector();
|
|
|
| Iterator keys = emailAttributes.keySet().iterator();
|
|
|
| StringBuffer debugStringBuffer = new StringBuffer();
|
|
|
| while (keys.hasNext()) {
|
| String key = (String) keys.next();
|
| Object val = emailAttributes.get(key);
|
|
| NameValue nv;
|
|
| if (val == null) {
|
| nv = new NameValue(key, "");
| } else {
|
| nv = new NameValue(key, val.toString());
| }
|
| list.addElement(nv);
|
| }
|
|
| NameValue[] nvl = new NameValue[list.size()+2];
|
|
|
| for (int i = 0; i < list.size(); i++) {
| nvl = (NameValue) list.elementAt(i);
|
| }
|
|
| NameValue nv=new NameValue("emailType",emailType);
| nvl[list.size()]=nv;
|
| nv=new NameValue("orderId","-1");
| nvl[list.size()+1]=nv;
|
| System.out.println("inside VitriaUtil 1");
|
| ObjectMessage message =session.createObjectMessage(nvl);
|
| Queue queue=(Queue)context.lookup(Constants.QUEUE_NAME);
| QueueSender publisher=session.createSender(queue);
| publisher.send(message);
| publisher.close();
| closeConnection();
| System.out.println("message sent");
| }
|
| public static void closeConnection(){
| try{
| conn.close();
| }catch(Exception e){
| e.printStackTrace();
| }
| }
|
|
|
| }
Is there something wrong in the code? or is it related something with size of Queue?
I am using the default values for the creation of the Queue.
And i am using Jboss-4.2.1G.A,jboss-messaging-1.3.0.GA and jboss-remoting-2_2_2_SP4.
Please let me know.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4174531#4174531
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4174531
17 years, 10 months
[Persistence, JBoss/CMP, Hibernate, Database] - Jboss Server Crashed ! ! !
by gothemilan
Hi,
Is there any one who can support to resolve the issue?
This is really stucking my life using Jboss server 4.0.3 SP 1. We've the application using JAVA/JSP and Jboss server to serve. And MSSQL server 2000 as a backend database server and MERLIA.jar to connect.
Here, what we are experiencing is; we need to send more than 100,000 emails a week and after sending out all emails (100,000 emails (email size is about 45kb per email)) the jboss server automaticall down and we will need to restart the jboss.
We've the file named mssql-ds.xml to for database connetion:
------------------------------------------------------------------
<local-tx-datasource>
<jndi-name>MerliaDS</jndi-name>
<connection-url>jdbc:inetdae7:192.168.1.11:1433?database=TPR</connection-url>
<driver-class>com.inet.tds.TdsDataSource</driver-class>
<user-name>sa</user-name>
pxgTGK23
<min-pool-size>300</min-pool-size>
<max-pool-size>500</max-pool-size>
<blocking-timeout-millis>30000</blocking-timeout-millis>
<idle-timeout-minutes>10</idle-timeout-minutes>
<check-valid-connection-sql>SELECT 1</check-valid-connection-sql>
<!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
<type-mapping>MS SQLSERVER2000</type-mapping>
</local-tx-datasource>
--------------------------------------------------------------------------------------
What could be the possible cause of jboss crash again again!!!!
Any Information and solution would be greatly appreciated.
Thanks in Advance. This is really emergency.
Regards,
Milan Gothe
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4174526#4174526
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4174526
17 years, 10 months