I did some more reading on SASL. As I mentioned earlier, it is a challenge/response based mechanism between the client and the server. So there will be multiple message flow between the client and server.
In the case of EJB invocations, there is a notion of clients and servers. In the case of web invocations, there is just server that we are dealing with.
Scott, do you think we should make an attempt at SASL? The details will be hidden behind the Security Client implementation and server side security manager implementation.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041679#4041679
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041679
I have been using jboss 2.4 for a while and built an own "portalservice package" that creates various portalobjects like pages, windows and portletinstances purely by the api (not with management portlet).
Now I have upgraded to portal 2.6 and my code breaks because when I want to fetch a portalobject i cant use Strings to the portalobjectcontainer. getObject requires an PortalObjectId.
I am having trouble to get a portalobject by its name. I have a page under default portal and when I do this
PortalObjectId id = PortalObjectId.parse(parentpage, PortalObjectId.LEGACY_FORMAT);
I get null when I do
PortalObject segmentpage = portalobjectcontainer.getObject(id);
I am expecting my page as a page direct under the default portal root.
How do I get an arbritrary portalobject from the portal object container?
knowing only the name of the page I want?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041647#4041647
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041647
There have been usage of SecurityAssociation directly in the client code by users as well as JEMS projects. We really need to be getting a Client SPI from the security project.
The SPI should include things like passage of username/password, callback handler, jaas config name (if the SPI implementation has to do JAAS).
The SPI implementation can make use of SASL on which GSS can be placed. GSS works on the concept of tokens and can use encryption.
One concept that I have not checked out is whether SASL needs both SASL client as well as SASL server because SASL is primarily used for a challenge/response type scenario. I want to be just doing SASL client.
A rough outline of the security client spi is:
| public interface SecurityClient
| public void setUserName(String username)
| public void setPrincipal(Principal p)
| public void setCredential(Object cred)
| public void setJaasConfigName(String str)
| //Advanced stuff for GSS
| public setEncryption(String algo)
I will work out the SPI in the next few days.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041574#4041574
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041574
I wouldn't hold your breath on any Kosmos package working. I've spent a couple of weeks messing around with JBoss, LifeRay and eXo. In all those install attempts the documentation for Kosmos has been next to useless, the build and/or deployment scripts have been broken or were missing so many elements needed in the classpath. I spent an entire day downloading and searching the web for halfbaked open source jar files that the process became a joke and some local developers started taking bets on how many more addons I would need just to get the LifeRay/Kosmos war file deployment script to complete successfully. BTW, you are correct, Build Successful means absolutely nothing with these scripts.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041504#4041504
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041504
I had a discussion with Scott on this. The invocation object creators should not be dealing with the security aspects. I will need to establish the security aspects via an interceptor after the container.
For the client side, people should not be doing any direct SecurityAssociation stuff. JAAS is ok. The security project should really be providing a client SPI for clients to use. JAAS etc should be an internal detail of the SPI. GSS/SASL type of framework is where we intend to go towards that will provide pluggable aspects semantics for security.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041485#4041485
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041485