Friday, February 15, 2008
Wednesday, February 6, 2008
Single SignOn (SSO) with Seam using JOSSO
I recently used seam_gen to create a josso_console application. If you want to use JOSSO, but you don't yet want to take the leap to hook it up to an LDAP or other industrial strength credential store, then this is the app may come in handly. Figure 1 shows the welcome screen of josso_console application.
Figure 1. The JOSSO console.
If your objective is simply to hook your Seam application up to JOSSO then you should keep reading too.
1. Seam and JAAS
Seam comes with its own security framework which is based on JAAS. The easiest way to hook Seam up to JOSSO is to first configure your Seam-based application the conventional JOSSO way and then hooking up Seam and JOSSO using a Seam authenticator. I worked on a jossoAuthenticator that will set the SSO user and roles information into Seam context, so that you can use all the Seam security features while using JOSSO.
2. Configure JOSSO
In your josso-agent-config.xml add the josso_console in as a partner app
Now your application will have access to the JOSSO cookie.
3. Configure Seam
Next we're going to protect our application using the standard security constraints to the web.xml. For instance if we only want users that have the admin role to access our console you would add
This web.xml references the login-redirect.jsp which you will need to add to the root of your war file. Now, you will be redirected to the josso login screen when trying to access the web application.
Next we have to propagate the authorization information into Seam context. For this we use the jossoAuthenticator.
Next you need to reference this class in your pages.xml, by adding
and commenting out the default authenticator
Finally we need to modify the pages.xml, where we reference the jossoAuthenticator on our welcome page (index.xhtml) like
which will cause the jossoAuthenticator.checkLogin to be called for this page, and in the exception class configuration we specify the index.xhtml page
All should now be working. If you want, you can obtain the full sources from the josso_console application to see the complete application.
Some other resources in this context you may find useful are:
http://www.josso.org/confluence/display/JOSSO1/JBoss+4.2
http://sdudzin.blogspot.com/2007/12/windows-sso-with-jboss-seam.html, and
http://www.ja-sig.org/wiki/display/CASC/Seam+Identity+Integration+(Seam+1.2.1+-+2.0.0)
Figure 1. The JOSSO console.
If your objective is simply to hook your Seam application up to JOSSO then you should keep reading too.
1. Seam and JAAS
Seam comes with its own security framework which is based on JAAS. The easiest way to hook Seam up to JOSSO is to first configure your Seam-based application the conventional JOSSO way and then hooking up Seam and JOSSO using a Seam authenticator. I worked on a jossoAuthenticator that will set the SSO user and roles information into Seam context, so that you can use all the Seam security features while using JOSSO.
2. Configure JOSSO
In your josso-agent-config.xml add the josso_console in as a partner app
Now your application will have access to the JOSSO cookie.
3. Configure Seam
Next we're going to protect our application using the standard security constraints to the web.xml. For instance if we only want users that have the admin role to access our console you would add
This web.xml references the login-redirect.jsp which you will need to add to the root of your war file. Now, you will be redirected to the josso login screen when trying to access the web application.
Next we have to propagate the authorization information into Seam context. For this we use the jossoAuthenticator.
Next you need to reference this class in your pages.xml, by adding
and commenting out the default authenticator
Finally we need to modify the pages.xml, where we reference the jossoAuthenticator on our welcome page (index.xhtml) like
which will cause the jossoAuthenticator.checkLogin to be called for this page, and in the exception class configuration we specify the index.xhtml page
All should now be working. If you want, you can obtain the full sources from the josso_console application to see the complete application.
Some other resources in this context you may find useful are:
http://www.josso.org/confluence/display/JOSSO1/JBoss+4.2
http://sdudzin.blogspot.com/2007/12/windows-sso-with-jboss-seam.html, and
http://www.ja-sig.org/wiki/display/CASC/Seam+Identity+Integration+(Seam+1.2.1+-+2.0.0)
Tuesday, February 5, 2008
Sony Vaio VGN-FS740/W Battery Problem
The battery on my wife's computer would no longer hold a charge and it was time to replace it. We replaced it with a generic brand battery (little more then $100). It charged fine, but then while it was running a message would suddenly pop up, saying that the battery was not inserted correctly and that it had to switch to hibernate mode. The battery light would flash rapidly after this, and it would never come back long or it would go hibernate again. Re-seating the battery had no effect. It turns out that Sony truly has turned evil. They are running a little service that checks whether the battery is a Sony battery ($300!), and if it is not then it kicks into action and sends your machine into hibernation!
After some digging I found this article, and the fix is easy, the service is called ISBMgr and to get rid of it permanently fire up msconfig like so
go to the startup tab and uncheck the ISBMgr.
Now when you restart it will ask you if you knew that some services where changed, just say yes and it will never bother you again.
Bad Sony. No more Sony for me..
After some digging I found this article, and the fix is easy, the service is called ISBMgr and to get rid of it permanently fire up msconfig like so
go to the startup tab and uncheck the ISBMgr.
Now when you restart it will ask you if you knew that some services where changed, just say yes and it will never bother you again.
Bad Sony. No more Sony for me..
Thursday, January 31, 2008
Compare two OpenOffice Documents
I received some feedback on a document I wrote and I wanted to know what the changes were. In Word you can track the changes, but where is this functionality in OpenOffice? I looked around a bit and found this really nice feature I had been missing - it is the 'compare document' feature, and it allows you to accept changes on a per diff level. Simply open the original document and then under Edit, select the 'Compare Document...'
and browse to the edited version document. After that it will bring up a nice dialog box with all the diffs which you can accept or deny. I think it makes a lot of sense not to do this in the document itself like Word does.
and browse to the edited version document. After that it will bring up a nice dialog box with all the diffs which you can accept or deny. I think it makes a lot of sense not to do this in the document itself like Word does.
Wednesday, January 30, 2008
Post XML code fragments
It turns out that it is not that straightforward to display XML fragments in a blog. Usually I use GeSHi to do the formatting for me. I then look at the source for the HTML page and grab the piece that I need, which I then host on my own site, and I reference it in an iframe like
Switch jUDDI on JBossESB over to Postgres
By default JBossESB uses HSQL to handle persistence for jUDDI. For production it is recommended to switch it to for example Postgres.
1. First you will need to download the Postgres JDBC driver. I selected the '8.2-507 JDBC 2EE' driver. You can copy it to either the jboss_home/server/default/lib directory, or to the jbossesb.sar/lib directory.
2. Create the juddi database. Run the pgAdmin a shown in Figure 1.
Figure 1. The Postgres Admin
and create a juddi user, which has create rights to create tables, see Figure 2.
Figure 2. Add a user called 'juddi'
3. Next you should update the datasource for jUDDI, which is defined in the jbossesb.sar/juddi-ds.xml. Comment out the Hypersonic configuration and add the postgres datasource configuration like
4. Finally we have to tell jUDDI where it can find the DDL to create the juddi schema. For this we edit the jbossesb.sar/esb.juddi.xml. Modify the 'juddi.sqlFiles' setting by replacing the 'hsqldb' occurances to 'postgresql'.
Now on startup JBossESB will create the jUDDI tables in the Postgres juddi database.
For an overview of jUDDI in JBossESB in pdf format see the Registry Guide.
1. First you will need to download the Postgres JDBC driver. I selected the '8.2-507 JDBC 2EE' driver. You can copy it to either the jboss_home/server/default/lib directory, or to the jbossesb.sar/lib directory.
2. Create the juddi database. Run the pgAdmin a shown in Figure 1.
Figure 1. The Postgres Admin
and create a juddi user, which has create rights to create tables, see Figure 2.
Figure 2. Add a user called 'juddi'
3. Next you should update the datasource for jUDDI, which is defined in the jbossesb.sar/juddi-ds.xml. Comment out the Hypersonic configuration and add the postgres datasource configuration like
4. Finally we have to tell jUDDI where it can find the DDL to create the juddi schema. For this we edit the jbossesb.sar/esb.juddi.xml. Modify the 'juddi.sqlFiles' setting by replacing the 'hsqldb' occurances to 'postgresql'.
Now on startup JBossESB will create the jUDDI tables in the Postgres juddi database.
For an overview of jUDDI in JBossESB in pdf format see the Registry Guide.
Friday, January 25, 2008
jBPM ant task to deploy a process definition to a running server
I've been working on jBPM integration into JBossESB to do Service Orchestration, and I created a new ant task to deploy a process definition to a running instance of jBPM. When I say a running instance I mean an instance that deploys the jBPM-console. The jBPM-console ships with a DeployerServlet which is used by the jBPM eclipse plugin to deploy process definitions. The ant task is called "DeployProcessToServerTask" and it uses the very same servlet. The java code for the task has been attached to jira JBPM-1117 so it should hopefully make it into SVN soon.
To use the DeployProcessToServer Task you need to define a new task using the taskdef command
So here I defined a task called 'deployToServer', but you can call it whatever you want. The classpath should obviously point to the jar containing this class. The 'deployToServer' can either deploy a Process Archive (PAR), which is a zip file containing the files you want to deploy, or you can specify a set of files which it will zip up and deploy for you. You can use the following attributes and subelements:
The following xml fragment deploys all the files in the processDefinition directory to the server
Or if you already have a par archive ready to go you could reference that
To use the DeployProcessToServer Task you need to define a new task using the taskdef command
<taskdef name="deployToServer" classname="org.jbpm.ant.DeployProcessToServerTask">
<classpath refid="exec-classpath"/>
</taskdef>
So here I defined a task called 'deployToServer', but you can call it whatever you want. The classpath should obviously point to the jar containing this class. The 'deployToServer' can either deploy a Process Archive (PAR), which is a zip file containing the files you want to deploy, or you can specify a set of files which it will zip up and deploy for you. You can use the following attributes and subelements:
| Attribute | Description | Default value |
|---|---|---|
| process | The location of process archive | - |
| servername | The name of the server which is used to build the deployment url | localhost |
| serverport | The port to which the http protocol is bound | 8080 |
| serverdeployer | The address of the deployer servlet | /jbpm-console/upload |
| debug | Debug flag which, if set, writes out a debug.par zip file. This is especially useful if fileSet subelements are used, so you can check what gets loaded to the server | - |
| SubElement | Description | Default value |
| fileSet | A fileSet element | - |
The following xml fragment deploys all the files in the processDefinition directory to the server
<target name="deployProcess" description="deploys the process definition">
<echo>Deploy the process definition</echo>
<taskdef name="deployToServer" classname="org.jbpm.ant.DeployProcessToServerTask">
<classpath refid="exec-classpath"/>
</taskdef>
<deployToServer>
<fileset dir="${basedir}/processDefinition" includes="*"/>
</deployToServer>
</target>
Or if you already have a par archive ready to go you could reference that
<target name="deployProcess" description="deploys the process definition">
<echo>Deploy the process definition</echo>
<taskdef name="deployToServer" classname="org.jbpm.ant.DeployProcessToServerTask">
<classpath refid="exec-classpath"/>
</taskdef>
<deployToServer process="${build}/process.par"/>
</target>
Subscribe to:
Posts (Atom)