You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by Quintin Beukes <qu...@last.za.net> on 2009/09/05 17:40:04 UTC
Login Contexts NOT working
My oh my this week has given me headaches. I went through hundreds of lines
of code for both geronimo and OpenEJB, and I can't seem to figure out why
this isn't working. From what I've found on the internet it should work
(unless I'm missing something).
OK. So I have this EJB:
@Stateless
@DeclareRoles( { "Admin" })
@RolesAllowed( { "Admin" })
public class TestBean implements TestRemote, TestLocal
{
@Resource
private SessionContext sessionCtx;
public String getInfo()
{
Principal p = sessionCtx.getCallerPrincipal();
StringBuilder sb = new StringBuilder();
sb.append("\n").append("Principal: " + p.getName() + " - type: " +
p.getClass().getCanonicalName());
return sb.toString();
}
}
getInfo() is a Remote method.
Then it's deploy plan contains:
<security doas-current-called="true" default-role="Admin">
</security>
And I do a remote lookup as follows:
Properties p = new Properties();
p.put("java.naming.factory.initial",
"org.apache.openejb.client.RemoteInitialContextFactory");
p.put("java.naming.provider.url", "ejbd://localhost:4201");
// user and pass optional
p.put("openejb.authentication.realmName", "KMSRealm");
p.put("java.naming.security.principal", "quintin");
p.put("java.naming.security.credentials", "pass");
InitialContext ctx = new InitialContext(p);
TestRemote myBean = (TestRemote) ctx.lookup("TestBeanRemote");
String info = myBean.getInfo();
When I run the code I get an: Exception in thread "main"
javax.ejb.EJBAccessException: Unauthorized Access by Principal Denied
So, I remove the security definitions from the EJB and it's deploy plan, the
method executes, and the Principal it returns is UnauthenticatedPrincipal.
KMSRealm is a server wide SQLLoginModule realm defined in the geronimo
console. I know the login works, because changing the InitialContext
credentials causes the login to fail. So all this works.
I am basically trying to login via EJB, and then be able to do two things
(1) define authorizations on the EJBs/methods (2) Retrieve the
Subject/Principal. Both of these are very important.
I've also tried replacing my <security> element in the deploy plan to this:
<security>
<default-subject>
<realm>KMSRealm</realm>
<id>quintin</id>
</default-subject>>
</security>
But then I get the following when deploying:
Error: Operation failed: start of kms/KMSPlatform-ejb/1.0/jar failed
Unknown start exception
Configuration kms/KMSPlatform-ejb/1.0/jar failed to start due to
the following reasons:
The service
EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=StatelessSessionBean,name=PersonnelBean
did not start because
kms/KMSPlatform-ejb/1.0/jar?EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
did not start.
The service
EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=StatelessSessionBean,name=TestBean
did not start because
kms/KMSPlatform-ejb/1.0/jar?EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
did not start.
The service
EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
did not start because Unknown realm: KMSRealm
I am up to my head in frustration. I gave Geronimo a try on a redev of a
project, but what took me about half a day to setup on Glassfish has now
taken me a week. Can anyone please help me out, because I really want to
have Geronimo's benefits in my applications.
--
Quintin Beukes
Re: Login Contexts NOT working
Posted by Quintin Beukes <qu...@skywalk.co.za>.
Hey,
Thanks for the mail. Cleared up 2 questions I had in my mind re. Geronimo.
I ended using a standalone SE application client. Mainly due to the
difficulty in distributing it via WebStart. This is unfortunately a
requirement, so network staff can quickly/easily install the client on
the staff machines, without having to carry around a disc. And since
we're contracted, updates are difficult as well. So with JNDI we just
upload the new jars and WS does the rest.
I love Geronimo though. It's fast - truly fast (compared to my
experiences with JBoss and Glassfish), and where I've used it before
(very limited use) it's rock solid. I had tons of Glassfish problems
with a specific project. One of them was bad, where JMS queues went
crazy and started delivering only months old data over and over, with
pauses in between where it's doing nothing. Repeating this cycle until
I reinstall it. And this even though it's accepting new messages all
the time. So I decided to port it to Geronimo, and it's working like a
charm. It was only 3 entities and an MDB, thus easier to setup.
I'll be very VERY busy this week. I'm a week behind. Serves me right
for using a new technology with poor support in my area, under such a
tight deadline. But I really wanted to *blink*. When I get some more
time I'll have a look at app client JNDI (like Glassfish does it -
which works well).
Then further, I was planning on building these for ourselves anyway,
so future developers can have things easier.
1. A standalone dependency generator (like the one in the WAR plan generator).
2. A plan generator for EJBs (any specific reason it's not there
yet... like "trickiness"?)
3. Ability to update/delete repository resources (the jar files)
If you can offer comments/pointers on any of these, would be appreciated.
Then lastly. Can you point me to some general Geronimo architecture
documentation? Like how maven fits into all this, how the plugin
layouts work, etc. Or should I just read Geronimo's + Maven's docs?
Will this be sufficient to get a good grounding in Geronimo's
internals?
Q
On Sun, Sep 6, 2009 at 7:17 PM, David Jencks <da...@yahoo.com> wrote:
> You might be confusing these two scenarios:
>
> 1. ee app client. Here, you specify a CallbackHandler that (in G.) gets run
> for you when the client starts, and you need to use the
> OpenejbRemoteLoginModule to do a remote login into the G. server. To access
> ejbs, you need to either use annotations or specify ejb-refs in the xml dd.
> If you use jndi, you should do...
>
> Context ctx = new InitialContext();
> MyEjb ejb = (MyEjb)ctx.lookup("java:comp'env/" + myEjbJndiName);
>
> Note that there are no properties in the new InitialContext() call.
>
> 2. non-ee app client. Here, you do what you want to obtain credentials and
> use the properties you show in your sample code to get a jndi context. You
> don't have an app client dd or annotations for the ejb refs. You'll need to
> find out the global jndi ejb names the ejbs are bound under.
>
> Most people end up using (2). There is no standardization among app server
> vendors for how ee app clients are started or distributed and its usually
> easier to just use something like a properties file to specify the jndi
> names for each app server if you need to deploy on more than one. I kinda
> like the idea of app clients but they do seem somewhat underspecified.
>
> A couple other comments....
>
> You shouldn't need the entire app server to run an ee app client, although I
> haven't done much experimentation with this. What I would do is to deploy
> your ear, and then in the admin console extract a custom server including
> the app client plugin. AFAIK no one has really looked at this yet so there
> is a very good chance that you will end up pulling in far more of the server
> than you need. However I'd guess you wouldn't get web, web services, jsps,
> etc.
>
> AFAIK no one has tried to figure out how to use webstart to distribute an ee
> app client. If I were to work on it I would start by making the server you
> get in the previous suggestion as small as possible, and then seeing if
> webstart gives you a means to unpack an artifact like that locally.
>
> When you say "GSS" what exactly do you mean? Are you trying to use
> kerberos? You may want to look into corba support since that provides a
> more sophisticated security system than openejb does natively, although it
> is somewhat difficult to understand how to set up.
>
> thanks
> david jencks
>
> On Sep 6, 2009, at 4:18 AM, Quintin Beukes wrote:
>
>> So my previous question basically asked how I can use JAAS on the
>> client side and still retrieve the InitialContext. When I login using
>> OpenejbRemoteLoginModule I see no way to retrieve the InitialContext
>> for that authenticated session.
>>
>> If I make a new connection I would have to send the credentials again
>> in a new connection. I would prefer not to do this, as it's a new
>> session and it leans towards bad practice. Things like reliable error
>> handling could possibly become problems, for example if the 2nd
>> connection fails. Sure I can add some complexity to get it to work
>> well, though I'm sure you can see why I don't want to make 2
>> connections just so I can use JAAS on the client side as well as get
>> the InitialContext.
>>
>> Just to explain, in case you maybe have a solution. I make a login
>> context like so:
>> loginConfiguration = ... load login configuration which references
>> OpenejbRemoteLoginModule ...
>> handler = new SomeCallbackHandler();
>> subject = new Subject();
>> loginContext = new LoginContext(LoginConfiguration.LOGIN_CONFIG_NAME,
>> subject, handler, loginConfiguration);
>>
>> Then I login and if successful, how do I retrieve the InitialContext?
>>
>> Q
>>
>> On Sun, Sep 6, 2009 at 1:02 PM, Quintin Beukes <qu...@skywalk.co.za>
>> wrote:
>>>
>>> I found the same. Take the following setup:
>>>
>>> Geronimo is installed in /opt/kms/server/geronimo. It's running from
>>> here where all the EJBs are installed.
>>>
>>> When I run the appclient with /opt/kms/server/geronimo/bin/client.sh I
>>> get an error about Derby already being started and it can't get locks
>>> on files.
>>>
>>> So I copy the Geronimo directory to /tmp/gclient, and try and run the
>>> client with /opt/gclient/bin/client.sh. Then it doesn't load the
>>> correct EJBs. Even though they're configured to authenticate via
>>> localhost:4201 (in the deploy gbean) and even if I use the remote bean
>>> interface.
>>>
>>> But it's not a big problem. The fact that you have to have the whole
>>> server foot print is not good, because we need webstart support. I
>>> started writing my own appclient and built a small framework for
>>> handling the application's login and InitialContext. It seems to be
>>> working well.
>>>
>>> Also, when I use the JAAS method and configure the
>>> OpenejbRemoteLoginModule in the JAAS login configuration, then I don't
>>> login to OpenEJB, and I can't access the InitialContext. I have to use
>>> the following to log into OpenEJB
>>>
>>> p.put(Context.INITIAL_CONTEXT_FACTORY, initialContextFactory);
>>> p.put(Context.PROVIDER_URL, serverURI.toString());
>>> p.put("openejb.authentication.realmName", securityRealm);
>>> p.put(Context.SECURITY_PRINCIPAL, userName);
>>> p.put(Context.SECURITY_CREDENTIALS, password);
>>>
>>> Where initialContextFactory is openEJB's RemoteInitialContext factory.
>>> Doing this I get an exception if the credentials are wrong, and handle
>>> the retries in my application.
>>>
>>> I'm not wrapped in the client framework this way, but it's sufficient.
>>> I'm also not using JAAS on the client side, so I'm not sure how I'm
>>> going to integrate GSS at a later time. Though when the time comes
>>> I'll handle it then. It shouldn't be too hard to change the login
>>> mechanism since I wrapped it all inside my own library, which has a
>>> fixed interface. So I should just be able to change the login
>>> mechanisms to JAAS. And since the server side still uses JAAS (it
>>> seems), I should probably just be able to propagate the details to the
>>> client and do the sign on with these details. This would be the first
>>> time I use GSS so I'm not really sure how it works.
>>>
>>> Q
>>>
>>> On Sun, Sep 6, 2009 at 9:08 AM, David Jencks <da...@yahoo.com>
>>> wrote:
>>>>
>>>> On Sep 5, 2009, at 10:11 AM, Quintin Beukes wrote:
>>>>
>>>> Hey David,
>>>>
>>>> Thanks for the response. The community for Geronimo seems very small, so
>>>> it's quite a lonely struggle.
>>>>
>>>> Either way. I finally got it right about 5 minutes ago, but yet again
>>>> have
>>>> another problem. This isn't so much as a problem as it is an unreachable
>>>> feature.
>>>>
>>>> Assume I get the IC as follows:
>>>>
>>>> Properties p = new Properties();
>>>> p.put("java.naming.factory.initial",
>>>> "org.apache.openejb.client.RemoteInitialContextFactory");
>>>> p.put("java.naming.provider.url", "ejbd://localhost:4201");
>>>> // user and pass optional
>>>> p.put("openejb.authentication.realmName", "KMSRealm");
>>>> p.put("java.naming.security.principal", "quintin");
>>>> p.put("java.naming.security.credentials", "pass");
>>>>
>>>> InitialContext ctx = new InitialContext(p);
>>>>
>>>> I am able to login and have the method authorizations work as intended
>>>> for
>>>> different users. The problem is that I use JAAS for the login and would
>>>> like
>>>> to use my own LoginModule. Is there anyway to have the above method use
>>>> JAAS
>>>> authentication with my own LoginModule?
>>>>
>>>> I'm not entirely sure what you are asking for. With what you describe
>>>> above, in the geronimo server you must have set up the KMSRealm
>>>> configuration using whatever login modules you want. So, you could pop
>>>> up a
>>>> swing login form in your client app and use those username/credentials
>>>> to
>>>> get the openejb initial context.
>>>> On the other hand, IIRC, if you use an ee app client with the "automated
>>>> login" when you provide a CallbackHandler, I think you want the client
>>>> login
>>>> to include pretty much only the OpenejbRemoteLoginModule which will
>>>> communicate to the openejb server and do an equivalent login using the
>>>> info
>>>> from your callback handler. Then if you use annotation based dependency
>>>> injection or lookup the ejbs in java:comp/env you won't need to do any
>>>> further login work.
>>>> The last time I looked at ee app clients I couldn't figure out how to
>>>> put
>>>> the app client on a different machine than the geronimo server. I
>>>> didn't
>>>> see code that supported this. I wouldn't think it would be hard to add
>>>> if
>>>> it is really missing.
>>>> thanks
>>>> david jencks
>>>>
>>>>
>>>>
>>>> Re. documentation, they are quite hard to find. They document the
>>>> features
>>>> but it's not always clear that a given document is what you're looking
>>>> for.
>>>> I sometimes read something and realize that a certain part of it might
>>>> help
>>>> me. I am, however, documenting my struggles on my blog, so hopefully
>>>> people
>>>> with similar problems can find an exact explanation on solving it.
>>>>
>>>> Further I also usually keep wikis for projects I use up to date, and
>>>> submit
>>>> patches for things I change. So whenever I get all these things working
>>>> and
>>>> back on track I will be contributing to the project, whether in
>>>> issues/features requests being reported, documentation/source patch
>>>> submissions or wiki updates.
>>>>
>>>> Q
>>>>
>>>> On Sat, Sep 5, 2009 at 6:55 PM, David Jencks <da...@yahoo.com>
>>>> wrote:
>>>>>
>>>>> On Sep 5, 2009, at 8:40 AM, Quintin Beukes wrote:
>>>>>
>>>>>> My oh my this week has given me headaches. I went through hundreds of
>>>>>> lines of code for both geronimo and OpenEJB, and I can't seem to
>>>>>> figure out
>>>>>> why this isn't working. From what I've found on the internet it should
>>>>>> work
>>>>>> (unless I'm missing something).
>>>>>>
>>>>>> OK. So I have this EJB:
>>>>>>
>>>>>> @Stateless
>>>>>> @DeclareRoles( { "Admin" })
>>>>>> @RolesAllowed( { "Admin" })
>>>>>> public class TestBean implements TestRemote, TestLocal
>>>>>> {
>>>>>> @Resource
>>>>>> private SessionContext sessionCtx;
>>>>>>
>>>>>> public String getInfo()
>>>>>> {
>>>>>> Principal p = sessionCtx.getCallerPrincipal();
>>>>>> StringBuilder sb = new StringBuilder();
>>>>>> sb.append("\n").append("Principal: " + p.getName() + " - type: " +
>>>>>> p.getClass().getCanonicalName());
>>>>>> return sb.toString();
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> getInfo() is a Remote method.
>>>>>>
>>>>>> Then it's deploy plan contains:
>>>>>> <security doas-current-called="true" default-role="Admin">
>>>>>>
>>>>>> </security>
>>>>>>
>>>>>> And I do a remote lookup as follows:
>>>>>>
>>>>>> Properties p = new Properties();
>>>>>> p.put("java.naming.factory.initial",
>>>>>> "org.apache.openejb.client.RemoteInitialContextFactory");
>>>>>> p.put("java.naming.provider.url", "ejbd://localhost:4201");
>>>>>> // user and pass optional
>>>>>> p.put("openejb.authentication.realmName", "KMSRealm");
>>>>>> p.put("java.naming.security.principal", "quintin");
>>>>>> p.put("java.naming.security.credentials", "pass");
>>>>>>
>>>>>> InitialContext ctx = new InitialContext(p);
>>>>>>
>>>>>> TestRemote myBean = (TestRemote) ctx.lookup("TestBeanRemote");
>>>>>> String info = myBean.getInfo();
>>>>>>
>>>>>> When I run the code I get an: Exception in thread "main"
>>>>>> javax.ejb.EJBAccessException: Unauthorized Access by Principal Denied
>>>>>>
>>>>>> So, I remove the security definitions from the EJB and it's deploy
>>>>>> plan,
>>>>>> the method executes, and the Principal it returns is
>>>>>> UnauthenticatedPrincipal.
>>>>>>
>>>>>> KMSRealm is a server wide SQLLoginModule realm defined in the geronimo
>>>>>> console. I know the login works, because changing the InitialContext
>>>>>> credentials causes the login to fail. So all this works.
>>>>>>
>>>>>> I am basically trying to login via EJB, and then be able to do two
>>>>>> things
>>>>>> (1) define authorizations on the EJBs/methods (2) Retrieve the
>>>>>> Subject/Principal. Both of these are very important.
>>>>>
>>>>> You need to map the prinicpal from the login module to the roles in
>>>>> your
>>>>> app, in your <security> element. Can you show what you have for this?
>>>>>
>>>>>
>>>>>>
>>>>>> I've also tried replacing my <security> element in the deploy plan to
>>>>>> this:
>>>>>> <security>
>>>>>> <default-subject>
>>>>>> <realm>KMSRealm</realm>
>>>>>> <id>quintin</id>
>>>>>> </default-subject>>
>>>>>> </security>
>>>>>
>>>>> If you use something like this you also need to set up a credential
>>>>> store
>>>>> that will log into your realm to get the Subject you are trying to
>>>>> specify
>>>>> here.
>>>>>
>>>>>>
>>>>>> But then I get the following when deploying:
>>>>>> Error: Operation failed: start of kms/KMSPlatform-ejb/1.0/jar failed
>>>>>>
>>>>>> Unknown start exception
>>>>>>
>>>>>> Configuration kms/KMSPlatform-ejb/1.0/jar failed to start
>>>>>> due
>>>>>> to
>>>>>> the following reasons:
>>>>>>
>>>>>> The service
>>>>>>
>>>>>>
>>>>>> EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=StatelessSessionBean,name=PersonnelBean
>>>>>> did not start because
>>>>>>
>>>>>>
>>>>>> kms/KMSPlatform-ejb/1.0/jar?EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
>>>>>> did not start.
>>>>>>
>>>>>> The service
>>>>>>
>>>>>>
>>>>>> EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=StatelessSessionBean,name=TestBean
>>>>>> did not start because
>>>>>>
>>>>>>
>>>>>> kms/KMSPlatform-ejb/1.0/jar?EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
>>>>>> did not start.
>>>>>>
>>>>>> The service
>>>>>>
>>>>>>
>>>>>> EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
>>>>>> did not start because Unknown realm: KMSRealm
>>>>>>
>>>>>> I am up to my head in frustration. I gave Geronimo a try on a redev of
>>>>>> a
>>>>>> project, but what took me about half a day to setup on Glassfish has
>>>>>> now
>>>>>> taken me a week. Can anyone please help me out, because I really want
>>>>>> to
>>>>>> have Geronimo's benefits in my applications.
>>>>>
>>>>> i have to run now, if these hints don't get you farther let us know and
>>>>> I'll try to be more detailed. I think there is some documentation at
>>>>> least
>>>>> in the 2.2 docs for both of these. If they are hard to find and you
>>>>> can
>>>>> think of better ways to get to them please let us know.
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>>> --
>>>>>> Quintin Beukes
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Quintin Beukes
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Quintin Beukes
>>>
>>
>>
>>
>> --
>> Quintin Beukes
>
>
--
Quintin Beukes
Re: Login Contexts NOT working
Posted by David Jencks <da...@yahoo.com>.
You might be confusing these two scenarios:
1. ee app client. Here, you specify a CallbackHandler that (in G.)
gets run for you when the client starts, and you need to use the
OpenejbRemoteLoginModule to do a remote login into the G. server. To
access ejbs, you need to either use annotations or specify ejb-refs in
the xml dd. If you use jndi, you should do...
Context ctx = new InitialContext();
MyEjb ejb = (MyEjb)ctx.lookup("java:comp'env/" + myEjbJndiName);
Note that there are no properties in the new InitialContext() call.
2. non-ee app client. Here, you do what you want to obtain
credentials and use the properties you show in your sample code to get
a jndi context. You don't have an app client dd or annotations for
the ejb refs. You'll need to find out the global jndi ejb names the
ejbs are bound under.
Most people end up using (2). There is no standardization among app
server vendors for how ee app clients are started or distributed and
its usually easier to just use something like a properties file to
specify the jndi names for each app server if you need to deploy on
more than one. I kinda like the idea of app clients but they do seem
somewhat underspecified.
A couple other comments....
You shouldn't need the entire app server to run an ee app client,
although I haven't done much experimentation with this. What I would
do is to deploy your ear, and then in the admin console extract a
custom server including the app client plugin. AFAIK no one has
really looked at this yet so there is a very good chance that you will
end up pulling in far more of the server than you need. However I'd
guess you wouldn't get web, web services, jsps, etc.
AFAIK no one has tried to figure out how to use webstart to distribute
an ee app client. If I were to work on it I would start by making the
server you get in the previous suggestion as small as possible, and
then seeing if webstart gives you a means to unpack an artifact like
that locally.
When you say "GSS" what exactly do you mean? Are you trying to use
kerberos? You may want to look into corba support since that provides
a more sophisticated security system than openejb does natively,
although it is somewhat difficult to understand how to set up.
thanks
david jencks
On Sep 6, 2009, at 4:18 AM, Quintin Beukes wrote:
> So my previous question basically asked how I can use JAAS on the
> client side and still retrieve the InitialContext. When I login using
> OpenejbRemoteLoginModule I see no way to retrieve the InitialContext
> for that authenticated session.
>
> If I make a new connection I would have to send the credentials again
> in a new connection. I would prefer not to do this, as it's a new
> session and it leans towards bad practice. Things like reliable error
> handling could possibly become problems, for example if the 2nd
> connection fails. Sure I can add some complexity to get it to work
> well, though I'm sure you can see why I don't want to make 2
> connections just so I can use JAAS on the client side as well as get
> the InitialContext.
>
> Just to explain, in case you maybe have a solution. I make a login
> context like so:
> loginConfiguration = ... load login configuration which references
> OpenejbRemoteLoginModule ...
> handler = new SomeCallbackHandler();
> subject = new Subject();
> loginContext = new LoginContext(LoginConfiguration.LOGIN_CONFIG_NAME,
> subject, handler, loginConfiguration);
>
> Then I login and if successful, how do I retrieve the InitialContext?
>
> Q
>
> On Sun, Sep 6, 2009 at 1:02 PM, Quintin Beukes
> <qu...@skywalk.co.za> wrote:
>> I found the same. Take the following setup:
>>
>> Geronimo is installed in /opt/kms/server/geronimo. It's running from
>> here where all the EJBs are installed.
>>
>> When I run the appclient with /opt/kms/server/geronimo/bin/
>> client.sh I
>> get an error about Derby already being started and it can't get locks
>> on files.
>>
>> So I copy the Geronimo directory to /tmp/gclient, and try and run the
>> client with /opt/gclient/bin/client.sh. Then it doesn't load the
>> correct EJBs. Even though they're configured to authenticate via
>> localhost:4201 (in the deploy gbean) and even if I use the remote
>> bean
>> interface.
>>
>> But it's not a big problem. The fact that you have to have the whole
>> server foot print is not good, because we need webstart support. I
>> started writing my own appclient and built a small framework for
>> handling the application's login and InitialContext. It seems to be
>> working well.
>>
>> Also, when I use the JAAS method and configure the
>> OpenejbRemoteLoginModule in the JAAS login configuration, then I
>> don't
>> login to OpenEJB, and I can't access the InitialContext. I have to
>> use
>> the following to log into OpenEJB
>>
>> p.put(Context.INITIAL_CONTEXT_FACTORY, initialContextFactory);
>> p.put(Context.PROVIDER_URL, serverURI.toString());
>> p.put("openejb.authentication.realmName", securityRealm);
>> p.put(Context.SECURITY_PRINCIPAL, userName);
>> p.put(Context.SECURITY_CREDENTIALS, password);
>>
>> Where initialContextFactory is openEJB's RemoteInitialContext
>> factory.
>> Doing this I get an exception if the credentials are wrong, and
>> handle
>> the retries in my application.
>>
>> I'm not wrapped in the client framework this way, but it's
>> sufficient.
>> I'm also not using JAAS on the client side, so I'm not sure how I'm
>> going to integrate GSS at a later time. Though when the time comes
>> I'll handle it then. It shouldn't be too hard to change the login
>> mechanism since I wrapped it all inside my own library, which has a
>> fixed interface. So I should just be able to change the login
>> mechanisms to JAAS. And since the server side still uses JAAS (it
>> seems), I should probably just be able to propagate the details to
>> the
>> client and do the sign on with these details. This would be the first
>> time I use GSS so I'm not really sure how it works.
>>
>> Q
>>
>> On Sun, Sep 6, 2009 at 9:08 AM, David Jencks
>> <da...@yahoo.com> wrote:
>>>
>>> On Sep 5, 2009, at 10:11 AM, Quintin Beukes wrote:
>>>
>>> Hey David,
>>>
>>> Thanks for the response. The community for Geronimo seems very
>>> small, so
>>> it's quite a lonely struggle.
>>>
>>> Either way. I finally got it right about 5 minutes ago, but yet
>>> again have
>>> another problem. This isn't so much as a problem as it is an
>>> unreachable
>>> feature.
>>>
>>> Assume I get the IC as follows:
>>>
>>> Properties p = new Properties();
>>> p.put("java.naming.factory.initial",
>>> "org.apache.openejb.client.RemoteInitialContextFactory");
>>> p.put("java.naming.provider.url", "ejbd://localhost:4201");
>>> // user and pass optional
>>> p.put("openejb.authentication.realmName", "KMSRealm");
>>> p.put("java.naming.security.principal", "quintin");
>>> p.put("java.naming.security.credentials", "pass");
>>>
>>> InitialContext ctx = new InitialContext(p);
>>>
>>> I am able to login and have the method authorizations work as
>>> intended for
>>> different users. The problem is that I use JAAS for the login and
>>> would like
>>> to use my own LoginModule. Is there anyway to have the above
>>> method use JAAS
>>> authentication with my own LoginModule?
>>>
>>> I'm not entirely sure what you are asking for. With what you
>>> describe
>>> above, in the geronimo server you must have set up the KMSRealm
>>> configuration using whatever login modules you want. So, you
>>> could pop up a
>>> swing login form in your client app and use those username/
>>> credentials to
>>> get the openejb initial context.
>>> On the other hand, IIRC, if you use an ee app client with the
>>> "automated
>>> login" when you provide a CallbackHandler, I think you want the
>>> client login
>>> to include pretty much only the OpenejbRemoteLoginModule which will
>>> communicate to the openejb server and do an equivalent login using
>>> the info
>>> from your callback handler. Then if you use annotation based
>>> dependency
>>> injection or lookup the ejbs in java:comp/env you won't need to do
>>> any
>>> further login work.
>>> The last time I looked at ee app clients I couldn't figure out how
>>> to put
>>> the app client on a different machine than the geronimo server. I
>>> didn't
>>> see code that supported this. I wouldn't think it would be hard
>>> to add if
>>> it is really missing.
>>> thanks
>>> david jencks
>>>
>>>
>>>
>>> Re. documentation, they are quite hard to find. They document the
>>> features
>>> but it's not always clear that a given document is what you're
>>> looking for.
>>> I sometimes read something and realize that a certain part of it
>>> might help
>>> me. I am, however, documenting my struggles on my blog, so
>>> hopefully people
>>> with similar problems can find an exact explanation on solving it.
>>>
>>> Further I also usually keep wikis for projects I use up to date,
>>> and submit
>>> patches for things I change. So whenever I get all these things
>>> working and
>>> back on track I will be contributing to the project, whether in
>>> issues/features requests being reported, documentation/source patch
>>> submissions or wiki updates.
>>>
>>> Q
>>>
>>> On Sat, Sep 5, 2009 at 6:55 PM, David Jencks
>>> <da...@yahoo.com> wrote:
>>>>
>>>> On Sep 5, 2009, at 8:40 AM, Quintin Beukes wrote:
>>>>
>>>>> My oh my this week has given me headaches. I went through
>>>>> hundreds of
>>>>> lines of code for both geronimo and OpenEJB, and I can't seem to
>>>>> figure out
>>>>> why this isn't working. From what I've found on the internet it
>>>>> should work
>>>>> (unless I'm missing something).
>>>>>
>>>>> OK. So I have this EJB:
>>>>>
>>>>> @Stateless
>>>>> @DeclareRoles( { "Admin" })
>>>>> @RolesAllowed( { "Admin" })
>>>>> public class TestBean implements TestRemote, TestLocal
>>>>> {
>>>>> @Resource
>>>>> private SessionContext sessionCtx;
>>>>>
>>>>> public String getInfo()
>>>>> {
>>>>> Principal p = sessionCtx.getCallerPrincipal();
>>>>> StringBuilder sb = new StringBuilder();
>>>>> sb.append("\n").append("Principal: " + p.getName() + " -
>>>>> type: " +
>>>>> p.getClass().getCanonicalName());
>>>>> return sb.toString();
>>>>> }
>>>>> }
>>>>>
>>>>> getInfo() is a Remote method.
>>>>>
>>>>> Then it's deploy plan contains:
>>>>> <security doas-current-called="true" default-role="Admin">
>>>>>
>>>>> </security>
>>>>>
>>>>> And I do a remote lookup as follows:
>>>>>
>>>>> Properties p = new Properties();
>>>>> p.put("java.naming.factory.initial",
>>>>> "org.apache.openejb.client.RemoteInitialContextFactory");
>>>>> p.put("java.naming.provider.url", "ejbd://localhost:4201");
>>>>> // user and pass optional
>>>>> p.put("openejb.authentication.realmName", "KMSRealm");
>>>>> p.put("java.naming.security.principal", "quintin");
>>>>> p.put("java.naming.security.credentials", "pass");
>>>>>
>>>>> InitialContext ctx = new InitialContext(p);
>>>>>
>>>>> TestRemote myBean = (TestRemote) ctx.lookup("TestBeanRemote");
>>>>> String info = myBean.getInfo();
>>>>>
>>>>> When I run the code I get an: Exception in thread "main"
>>>>> javax.ejb.EJBAccessException: Unauthorized Access by Principal
>>>>> Denied
>>>>>
>>>>> So, I remove the security definitions from the EJB and it's
>>>>> deploy plan,
>>>>> the method executes, and the Principal it returns is
>>>>> UnauthenticatedPrincipal.
>>>>>
>>>>> KMSRealm is a server wide SQLLoginModule realm defined in the
>>>>> geronimo
>>>>> console. I know the login works, because changing the
>>>>> InitialContext
>>>>> credentials causes the login to fail. So all this works.
>>>>>
>>>>> I am basically trying to login via EJB, and then be able to do
>>>>> two things
>>>>> (1) define authorizations on the EJBs/methods (2) Retrieve the
>>>>> Subject/Principal. Both of these are very important.
>>>>
>>>> You need to map the prinicpal from the login module to the roles
>>>> in your
>>>> app, in your <security> element. Can you show what you have for
>>>> this?
>>>>
>>>>
>>>>>
>>>>> I've also tried replacing my <security> element in the deploy
>>>>> plan to
>>>>> this:
>>>>> <security>
>>>>> <default-subject>
>>>>> <realm>KMSRealm</realm>
>>>>> <id>quintin</id>
>>>>> </default-subject>>
>>>>> </security>
>>>>
>>>> If you use something like this you also need to set up a
>>>> credential store
>>>> that will log into your realm to get the Subject you are trying
>>>> to specify
>>>> here.
>>>>
>>>>>
>>>>> But then I get the following when deploying:
>>>>> Error: Operation failed: start of kms/KMSPlatform-ejb/1.0/jar
>>>>> failed
>>>>>
>>>>> Unknown start exception
>>>>>
>>>>> Configuration kms/KMSPlatform-ejb/1.0/jar failed to
>>>>> start due
>>>>> to
>>>>> the following reasons:
>>>>>
>>>>> The service
>>>>>
>>>>> EJBModule=kms/KMSPlatform-ejb/1.0/
>>>>> jar
>>>>> ,J2EEApplication
>>>>> =null,j2eeType=StatelessSessionBean,name=PersonnelBean
>>>>> did not start because
>>>>>
>>>>> kms/KMSPlatform-ejb/1.0/jar?EJBModule=kms/KMSPlatform-ejb/1.0/
>>>>> jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
>>>>> did not start.
>>>>>
>>>>> The service
>>>>>
>>>>> EJBModule=kms/KMSPlatform-ejb/1.0/
>>>>> jar
>>>>> ,J2EEApplication=null,j2eeType=StatelessSessionBean,name=TestBean
>>>>> did not start because
>>>>>
>>>>> kms/KMSPlatform-ejb/1.0/jar?EJBModule=kms/KMSPlatform-ejb/1.0/
>>>>> jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
>>>>> did not start.
>>>>>
>>>>> The service
>>>>>
>>>>> EJBModule=kms/KMSPlatform-ejb/1.0/
>>>>> jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
>>>>> did not start because Unknown realm: KMSRealm
>>>>>
>>>>> I am up to my head in frustration. I gave Geronimo a try on a
>>>>> redev of a
>>>>> project, but what took me about half a day to setup on Glassfish
>>>>> has now
>>>>> taken me a week. Can anyone please help me out, because I really
>>>>> want to
>>>>> have Geronimo's benefits in my applications.
>>>>
>>>> i have to run now, if these hints don't get you farther let us
>>>> know and
>>>> I'll try to be more detailed. I think there is some
>>>> documentation at least
>>>> in the 2.2 docs for both of these. If they are hard to find and
>>>> you can
>>>> think of better ways to get to them please let us know.
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>>> --
>>>>> Quintin Beukes
>>>>
>>>
>>>
>>>
>>> --
>>> Quintin Beukes
>>>
>>>
>>
>>
>>
>> --
>> Quintin Beukes
>>
>
>
>
> --
> Quintin Beukes
Re: Login Contexts NOT working
Posted by Quintin Beukes <qu...@skywalk.co.za>.
So my previous question basically asked how I can use JAAS on the
client side and still retrieve the InitialContext. When I login using
OpenejbRemoteLoginModule I see no way to retrieve the InitialContext
for that authenticated session.
If I make a new connection I would have to send the credentials again
in a new connection. I would prefer not to do this, as it's a new
session and it leans towards bad practice. Things like reliable error
handling could possibly become problems, for example if the 2nd
connection fails. Sure I can add some complexity to get it to work
well, though I'm sure you can see why I don't want to make 2
connections just so I can use JAAS on the client side as well as get
the InitialContext.
Just to explain, in case you maybe have a solution. I make a login
context like so:
loginConfiguration = ... load login configuration which references
OpenejbRemoteLoginModule ...
handler = new SomeCallbackHandler();
subject = new Subject();
loginContext = new LoginContext(LoginConfiguration.LOGIN_CONFIG_NAME,
subject, handler, loginConfiguration);
Then I login and if successful, how do I retrieve the InitialContext?
Q
On Sun, Sep 6, 2009 at 1:02 PM, Quintin Beukes <qu...@skywalk.co.za> wrote:
> I found the same. Take the following setup:
>
> Geronimo is installed in /opt/kms/server/geronimo. It's running from
> here where all the EJBs are installed.
>
> When I run the appclient with /opt/kms/server/geronimo/bin/client.sh I
> get an error about Derby already being started and it can't get locks
> on files.
>
> So I copy the Geronimo directory to /tmp/gclient, and try and run the
> client with /opt/gclient/bin/client.sh. Then it doesn't load the
> correct EJBs. Even though they're configured to authenticate via
> localhost:4201 (in the deploy gbean) and even if I use the remote bean
> interface.
>
> But it's not a big problem. The fact that you have to have the whole
> server foot print is not good, because we need webstart support. I
> started writing my own appclient and built a small framework for
> handling the application's login and InitialContext. It seems to be
> working well.
>
> Also, when I use the JAAS method and configure the
> OpenejbRemoteLoginModule in the JAAS login configuration, then I don't
> login to OpenEJB, and I can't access the InitialContext. I have to use
> the following to log into OpenEJB
>
> p.put(Context.INITIAL_CONTEXT_FACTORY, initialContextFactory);
> p.put(Context.PROVIDER_URL, serverURI.toString());
> p.put("openejb.authentication.realmName", securityRealm);
> p.put(Context.SECURITY_PRINCIPAL, userName);
> p.put(Context.SECURITY_CREDENTIALS, password);
>
> Where initialContextFactory is openEJB's RemoteInitialContext factory.
> Doing this I get an exception if the credentials are wrong, and handle
> the retries in my application.
>
> I'm not wrapped in the client framework this way, but it's sufficient.
> I'm also not using JAAS on the client side, so I'm not sure how I'm
> going to integrate GSS at a later time. Though when the time comes
> I'll handle it then. It shouldn't be too hard to change the login
> mechanism since I wrapped it all inside my own library, which has a
> fixed interface. So I should just be able to change the login
> mechanisms to JAAS. And since the server side still uses JAAS (it
> seems), I should probably just be able to propagate the details to the
> client and do the sign on with these details. This would be the first
> time I use GSS so I'm not really sure how it works.
>
> Q
>
> On Sun, Sep 6, 2009 at 9:08 AM, David Jencks <da...@yahoo.com> wrote:
>>
>> On Sep 5, 2009, at 10:11 AM, Quintin Beukes wrote:
>>
>> Hey David,
>>
>> Thanks for the response. The community for Geronimo seems very small, so
>> it's quite a lonely struggle.
>>
>> Either way. I finally got it right about 5 minutes ago, but yet again have
>> another problem. This isn't so much as a problem as it is an unreachable
>> feature.
>>
>> Assume I get the IC as follows:
>>
>> Properties p = new Properties();
>> p.put("java.naming.factory.initial",
>> "org.apache.openejb.client.RemoteInitialContextFactory");
>> p.put("java.naming.provider.url", "ejbd://localhost:4201");
>> // user and pass optional
>> p.put("openejb.authentication.realmName", "KMSRealm");
>> p.put("java.naming.security.principal", "quintin");
>> p.put("java.naming.security.credentials", "pass");
>>
>> InitialContext ctx = new InitialContext(p);
>>
>> I am able to login and have the method authorizations work as intended for
>> different users. The problem is that I use JAAS for the login and would like
>> to use my own LoginModule. Is there anyway to have the above method use JAAS
>> authentication with my own LoginModule?
>>
>> I'm not entirely sure what you are asking for. With what you describe
>> above, in the geronimo server you must have set up the KMSRealm
>> configuration using whatever login modules you want. So, you could pop up a
>> swing login form in your client app and use those username/credentials to
>> get the openejb initial context.
>> On the other hand, IIRC, if you use an ee app client with the "automated
>> login" when you provide a CallbackHandler, I think you want the client login
>> to include pretty much only the OpenejbRemoteLoginModule which will
>> communicate to the openejb server and do an equivalent login using the info
>> from your callback handler. Then if you use annotation based dependency
>> injection or lookup the ejbs in java:comp/env you won't need to do any
>> further login work.
>> The last time I looked at ee app clients I couldn't figure out how to put
>> the app client on a different machine than the geronimo server. I didn't
>> see code that supported this. I wouldn't think it would be hard to add if
>> it is really missing.
>> thanks
>> david jencks
>>
>>
>>
>> Re. documentation, they are quite hard to find. They document the features
>> but it's not always clear that a given document is what you're looking for.
>> I sometimes read something and realize that a certain part of it might help
>> me. I am, however, documenting my struggles on my blog, so hopefully people
>> with similar problems can find an exact explanation on solving it.
>>
>> Further I also usually keep wikis for projects I use up to date, and submit
>> patches for things I change. So whenever I get all these things working and
>> back on track I will be contributing to the project, whether in
>> issues/features requests being reported, documentation/source patch
>> submissions or wiki updates.
>>
>> Q
>>
>> On Sat, Sep 5, 2009 at 6:55 PM, David Jencks <da...@yahoo.com> wrote:
>>>
>>> On Sep 5, 2009, at 8:40 AM, Quintin Beukes wrote:
>>>
>>>> My oh my this week has given me headaches. I went through hundreds of
>>>> lines of code for both geronimo and OpenEJB, and I can't seem to figure out
>>>> why this isn't working. From what I've found on the internet it should work
>>>> (unless I'm missing something).
>>>>
>>>> OK. So I have this EJB:
>>>>
>>>> @Stateless
>>>> @DeclareRoles( { "Admin" })
>>>> @RolesAllowed( { "Admin" })
>>>> public class TestBean implements TestRemote, TestLocal
>>>> {
>>>> @Resource
>>>> private SessionContext sessionCtx;
>>>>
>>>> public String getInfo()
>>>> {
>>>> Principal p = sessionCtx.getCallerPrincipal();
>>>> StringBuilder sb = new StringBuilder();
>>>> sb.append("\n").append("Principal: " + p.getName() + " - type: " +
>>>> p.getClass().getCanonicalName());
>>>> return sb.toString();
>>>> }
>>>> }
>>>>
>>>> getInfo() is a Remote method.
>>>>
>>>> Then it's deploy plan contains:
>>>> <security doas-current-called="true" default-role="Admin">
>>>>
>>>> </security>
>>>>
>>>> And I do a remote lookup as follows:
>>>>
>>>> Properties p = new Properties();
>>>> p.put("java.naming.factory.initial",
>>>> "org.apache.openejb.client.RemoteInitialContextFactory");
>>>> p.put("java.naming.provider.url", "ejbd://localhost:4201");
>>>> // user and pass optional
>>>> p.put("openejb.authentication.realmName", "KMSRealm");
>>>> p.put("java.naming.security.principal", "quintin");
>>>> p.put("java.naming.security.credentials", "pass");
>>>>
>>>> InitialContext ctx = new InitialContext(p);
>>>>
>>>> TestRemote myBean = (TestRemote) ctx.lookup("TestBeanRemote");
>>>> String info = myBean.getInfo();
>>>>
>>>> When I run the code I get an: Exception in thread "main"
>>>> javax.ejb.EJBAccessException: Unauthorized Access by Principal Denied
>>>>
>>>> So, I remove the security definitions from the EJB and it's deploy plan,
>>>> the method executes, and the Principal it returns is
>>>> UnauthenticatedPrincipal.
>>>>
>>>> KMSRealm is a server wide SQLLoginModule realm defined in the geronimo
>>>> console. I know the login works, because changing the InitialContext
>>>> credentials causes the login to fail. So all this works.
>>>>
>>>> I am basically trying to login via EJB, and then be able to do two things
>>>> (1) define authorizations on the EJBs/methods (2) Retrieve the
>>>> Subject/Principal. Both of these are very important.
>>>
>>> You need to map the prinicpal from the login module to the roles in your
>>> app, in your <security> element. Can you show what you have for this?
>>>
>>>
>>>>
>>>> I've also tried replacing my <security> element in the deploy plan to
>>>> this:
>>>> <security>
>>>> <default-subject>
>>>> <realm>KMSRealm</realm>
>>>> <id>quintin</id>
>>>> </default-subject>>
>>>> </security>
>>>
>>> If you use something like this you also need to set up a credential store
>>> that will log into your realm to get the Subject you are trying to specify
>>> here.
>>>
>>>>
>>>> But then I get the following when deploying:
>>>> Error: Operation failed: start of kms/KMSPlatform-ejb/1.0/jar failed
>>>>
>>>> Unknown start exception
>>>>
>>>> Configuration kms/KMSPlatform-ejb/1.0/jar failed to start due
>>>> to
>>>> the following reasons:
>>>>
>>>> The service
>>>>
>>>> EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=StatelessSessionBean,name=PersonnelBean
>>>> did not start because
>>>>
>>>> kms/KMSPlatform-ejb/1.0/jar?EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
>>>> did not start.
>>>>
>>>> The service
>>>>
>>>> EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=StatelessSessionBean,name=TestBean
>>>> did not start because
>>>>
>>>> kms/KMSPlatform-ejb/1.0/jar?EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
>>>> did not start.
>>>>
>>>> The service
>>>>
>>>> EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
>>>> did not start because Unknown realm: KMSRealm
>>>>
>>>> I am up to my head in frustration. I gave Geronimo a try on a redev of a
>>>> project, but what took me about half a day to setup on Glassfish has now
>>>> taken me a week. Can anyone please help me out, because I really want to
>>>> have Geronimo's benefits in my applications.
>>>
>>> i have to run now, if these hints don't get you farther let us know and
>>> I'll try to be more detailed. I think there is some documentation at least
>>> in the 2.2 docs for both of these. If they are hard to find and you can
>>> think of better ways to get to them please let us know.
>>>
>>> thanks
>>> david jencks
>>>
>>>> --
>>>> Quintin Beukes
>>>
>>
>>
>>
>> --
>> Quintin Beukes
>>
>>
>
>
>
> --
> Quintin Beukes
>
--
Quintin Beukes
Re: Login Contexts NOT working
Posted by Quintin Beukes <qu...@skywalk.co.za>.
I found the same. Take the following setup:
Geronimo is installed in /opt/kms/server/geronimo. It's running from
here where all the EJBs are installed.
When I run the appclient with /opt/kms/server/geronimo/bin/client.sh I
get an error about Derby already being started and it can't get locks
on files.
So I copy the Geronimo directory to /tmp/gclient, and try and run the
client with /opt/gclient/bin/client.sh. Then it doesn't load the
correct EJBs. Even though they're configured to authenticate via
localhost:4201 (in the deploy gbean) and even if I use the remote bean
interface.
But it's not a big problem. The fact that you have to have the whole
server foot print is not good, because we need webstart support. I
started writing my own appclient and built a small framework for
handling the application's login and InitialContext. It seems to be
working well.
Also, when I use the JAAS method and configure the
OpenejbRemoteLoginModule in the JAAS login configuration, then I don't
login to OpenEJB, and I can't access the InitialContext. I have to use
the following to log into OpenEJB
p.put(Context.INITIAL_CONTEXT_FACTORY, initialContextFactory);
p.put(Context.PROVIDER_URL, serverURI.toString());
p.put("openejb.authentication.realmName", securityRealm);
p.put(Context.SECURITY_PRINCIPAL, userName);
p.put(Context.SECURITY_CREDENTIALS, password);
Where initialContextFactory is openEJB's RemoteInitialContext factory.
Doing this I get an exception if the credentials are wrong, and handle
the retries in my application.
I'm not wrapped in the client framework this way, but it's sufficient.
I'm also not using JAAS on the client side, so I'm not sure how I'm
going to integrate GSS at a later time. Though when the time comes
I'll handle it then. It shouldn't be too hard to change the login
mechanism since I wrapped it all inside my own library, which has a
fixed interface. So I should just be able to change the login
mechanisms to JAAS. And since the server side still uses JAAS (it
seems), I should probably just be able to propagate the details to the
client and do the sign on with these details. This would be the first
time I use GSS so I'm not really sure how it works.
Q
On Sun, Sep 6, 2009 at 9:08 AM, David Jencks <da...@yahoo.com> wrote:
>
> On Sep 5, 2009, at 10:11 AM, Quintin Beukes wrote:
>
> Hey David,
>
> Thanks for the response. The community for Geronimo seems very small, so
> it's quite a lonely struggle.
>
> Either way. I finally got it right about 5 minutes ago, but yet again have
> another problem. This isn't so much as a problem as it is an unreachable
> feature.
>
> Assume I get the IC as follows:
>
> Properties p = new Properties();
> p.put("java.naming.factory.initial",
> "org.apache.openejb.client.RemoteInitialContextFactory");
> p.put("java.naming.provider.url", "ejbd://localhost:4201");
> // user and pass optional
> p.put("openejb.authentication.realmName", "KMSRealm");
> p.put("java.naming.security.principal", "quintin");
> p.put("java.naming.security.credentials", "pass");
>
> InitialContext ctx = new InitialContext(p);
>
> I am able to login and have the method authorizations work as intended for
> different users. The problem is that I use JAAS for the login and would like
> to use my own LoginModule. Is there anyway to have the above method use JAAS
> authentication with my own LoginModule?
>
> I'm not entirely sure what you are asking for. With what you describe
> above, in the geronimo server you must have set up the KMSRealm
> configuration using whatever login modules you want. So, you could pop up a
> swing login form in your client app and use those username/credentials to
> get the openejb initial context.
> On the other hand, IIRC, if you use an ee app client with the "automated
> login" when you provide a CallbackHandler, I think you want the client login
> to include pretty much only the OpenejbRemoteLoginModule which will
> communicate to the openejb server and do an equivalent login using the info
> from your callback handler. Then if you use annotation based dependency
> injection or lookup the ejbs in java:comp/env you won't need to do any
> further login work.
> The last time I looked at ee app clients I couldn't figure out how to put
> the app client on a different machine than the geronimo server. I didn't
> see code that supported this. I wouldn't think it would be hard to add if
> it is really missing.
> thanks
> david jencks
>
>
>
> Re. documentation, they are quite hard to find. They document the features
> but it's not always clear that a given document is what you're looking for.
> I sometimes read something and realize that a certain part of it might help
> me. I am, however, documenting my struggles on my blog, so hopefully people
> with similar problems can find an exact explanation on solving it.
>
> Further I also usually keep wikis for projects I use up to date, and submit
> patches for things I change. So whenever I get all these things working and
> back on track I will be contributing to the project, whether in
> issues/features requests being reported, documentation/source patch
> submissions or wiki updates.
>
> Q
>
> On Sat, Sep 5, 2009 at 6:55 PM, David Jencks <da...@yahoo.com> wrote:
>>
>> On Sep 5, 2009, at 8:40 AM, Quintin Beukes wrote:
>>
>>> My oh my this week has given me headaches. I went through hundreds of
>>> lines of code for both geronimo and OpenEJB, and I can't seem to figure out
>>> why this isn't working. From what I've found on the internet it should work
>>> (unless I'm missing something).
>>>
>>> OK. So I have this EJB:
>>>
>>> @Stateless
>>> @DeclareRoles( { "Admin" })
>>> @RolesAllowed( { "Admin" })
>>> public class TestBean implements TestRemote, TestLocal
>>> {
>>> @Resource
>>> private SessionContext sessionCtx;
>>>
>>> public String getInfo()
>>> {
>>> Principal p = sessionCtx.getCallerPrincipal();
>>> StringBuilder sb = new StringBuilder();
>>> sb.append("\n").append("Principal: " + p.getName() + " - type: " +
>>> p.getClass().getCanonicalName());
>>> return sb.toString();
>>> }
>>> }
>>>
>>> getInfo() is a Remote method.
>>>
>>> Then it's deploy plan contains:
>>> <security doas-current-called="true" default-role="Admin">
>>>
>>> </security>
>>>
>>> And I do a remote lookup as follows:
>>>
>>> Properties p = new Properties();
>>> p.put("java.naming.factory.initial",
>>> "org.apache.openejb.client.RemoteInitialContextFactory");
>>> p.put("java.naming.provider.url", "ejbd://localhost:4201");
>>> // user and pass optional
>>> p.put("openejb.authentication.realmName", "KMSRealm");
>>> p.put("java.naming.security.principal", "quintin");
>>> p.put("java.naming.security.credentials", "pass");
>>>
>>> InitialContext ctx = new InitialContext(p);
>>>
>>> TestRemote myBean = (TestRemote) ctx.lookup("TestBeanRemote");
>>> String info = myBean.getInfo();
>>>
>>> When I run the code I get an: Exception in thread "main"
>>> javax.ejb.EJBAccessException: Unauthorized Access by Principal Denied
>>>
>>> So, I remove the security definitions from the EJB and it's deploy plan,
>>> the method executes, and the Principal it returns is
>>> UnauthenticatedPrincipal.
>>>
>>> KMSRealm is a server wide SQLLoginModule realm defined in the geronimo
>>> console. I know the login works, because changing the InitialContext
>>> credentials causes the login to fail. So all this works.
>>>
>>> I am basically trying to login via EJB, and then be able to do two things
>>> (1) define authorizations on the EJBs/methods (2) Retrieve the
>>> Subject/Principal. Both of these are very important.
>>
>> You need to map the prinicpal from the login module to the roles in your
>> app, in your <security> element. Can you show what you have for this?
>>
>>
>>>
>>> I've also tried replacing my <security> element in the deploy plan to
>>> this:
>>> <security>
>>> <default-subject>
>>> <realm>KMSRealm</realm>
>>> <id>quintin</id>
>>> </default-subject>>
>>> </security>
>>
>> If you use something like this you also need to set up a credential store
>> that will log into your realm to get the Subject you are trying to specify
>> here.
>>
>>>
>>> But then I get the following when deploying:
>>> Error: Operation failed: start of kms/KMSPlatform-ejb/1.0/jar failed
>>>
>>> Unknown start exception
>>>
>>> Configuration kms/KMSPlatform-ejb/1.0/jar failed to start due
>>> to
>>> the following reasons:
>>>
>>> The service
>>>
>>> EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=StatelessSessionBean,name=PersonnelBean
>>> did not start because
>>>
>>> kms/KMSPlatform-ejb/1.0/jar?EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
>>> did not start.
>>>
>>> The service
>>>
>>> EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=StatelessSessionBean,name=TestBean
>>> did not start because
>>>
>>> kms/KMSPlatform-ejb/1.0/jar?EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
>>> did not start.
>>>
>>> The service
>>>
>>> EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
>>> did not start because Unknown realm: KMSRealm
>>>
>>> I am up to my head in frustration. I gave Geronimo a try on a redev of a
>>> project, but what took me about half a day to setup on Glassfish has now
>>> taken me a week. Can anyone please help me out, because I really want to
>>> have Geronimo's benefits in my applications.
>>
>> i have to run now, if these hints don't get you farther let us know and
>> I'll try to be more detailed. I think there is some documentation at least
>> in the 2.2 docs for both of these. If they are hard to find and you can
>> think of better ways to get to them please let us know.
>>
>> thanks
>> david jencks
>>
>>> --
>>> Quintin Beukes
>>
>
>
>
> --
> Quintin Beukes
>
>
--
Quintin Beukes
Re: Login Contexts NOT working
Posted by David Jencks <da...@yahoo.com>.
On Sep 5, 2009, at 10:11 AM, Quintin Beukes wrote:
> Hey David,
>
> Thanks for the response. The community for Geronimo seems very
> small, so it's quite a lonely struggle.
>
> Either way. I finally got it right about 5 minutes ago, but yet
> again have another problem. This isn't so much as a problem as it is
> an unreachable feature.
>
> Assume I get the IC as follows:
>
> Properties p = new Properties();
> p.put("java.naming.factory.initial",
> "org.apache.openejb.client.RemoteInitialContextFactory");
> p.put("java.naming.provider.url", "ejbd://localhost:4201");
> // user and pass optional
> p.put("openejb.authentication.realmName", "KMSRealm");
> p.put("java.naming.security.principal", "quintin");
> p.put("java.naming.security.credentials", "pass");
>
> InitialContext ctx = new InitialContext(p);
>
> I am able to login and have the method authorizations work as
> intended for different users. The problem is that I use JAAS for the
> login and would like to use my own LoginModule. Is there anyway to
> have the above method use JAAS authentication with my own LoginModule?
I'm not entirely sure what you are asking for. With what you describe
above, in the geronimo server you must have set up the KMSRealm
configuration using whatever login modules you want. So, you could
pop up a swing login form in your client app and use those username/
credentials to get the openejb initial context.
On the other hand, IIRC, if you use an ee app client with the
"automated login" when you provide a CallbackHandler, I think you want
the client login to include pretty much only the
OpenejbRemoteLoginModule which will communicate to the openejb server
and do an equivalent login using the info from your callback handler.
Then if you use annotation based dependency injection or lookup the
ejbs in java:comp/env you won't need to do any further login work.
The last time I looked at ee app clients I couldn't figure out how to
put the app client on a different machine than the geronimo server. I
didn't see code that supported this. I wouldn't think it would be
hard to add if it is really missing.
thanks
david jencks
>
> Re. documentation, they are quite hard to find. They document the
> features but it's not always clear that a given document is what
> you're looking for. I sometimes read something and realize that a
> certain part of it might help me. I am, however, documenting my
> struggles on my blog, so hopefully people with similar problems can
> find an exact explanation on solving it.
>
> Further I also usually keep wikis for projects I use up to date, and
> submit patches for things I change. So whenever I get all these
> things working and back on track I will be contributing to the
> project, whether in issues/features requests being reported,
> documentation/source patch submissions or wiki updates.
>
> Q
>
> On Sat, Sep 5, 2009 at 6:55 PM, David Jencks
> <da...@yahoo.com> wrote:
>
> On Sep 5, 2009, at 8:40 AM, Quintin Beukes wrote:
>
> My oh my this week has given me headaches. I went through hundreds
> of lines of code for both geronimo and OpenEJB, and I can't seem to
> figure out why this isn't working. From what I've found on the
> internet it should work (unless I'm missing something).
>
> OK. So I have this EJB:
>
> @Stateless
> @DeclareRoles( { "Admin" })
> @RolesAllowed( { "Admin" })
> public class TestBean implements TestRemote, TestLocal
> {
> @Resource
> private SessionContext sessionCtx;
>
> public String getInfo()
> {
> Principal p = sessionCtx.getCallerPrincipal();
> StringBuilder sb = new StringBuilder();
> sb.append("\n").append("Principal: " + p.getName() + " - type: "
> + p.getClass().getCanonicalName());
> return sb.toString();
> }
> }
>
> getInfo() is a Remote method.
>
> Then it's deploy plan contains:
> <security doas-current-called="true" default-role="Admin">
>
> </security>
>
> And I do a remote lookup as follows:
>
> Properties p = new Properties();
> p.put("java.naming.factory.initial",
> "org.apache.openejb.client.RemoteInitialContextFactory");
> p.put("java.naming.provider.url", "ejbd://localhost:4201");
> // user and pass optional
> p.put("openejb.authentication.realmName", "KMSRealm");
> p.put("java.naming.security.principal", "quintin");
> p.put("java.naming.security.credentials", "pass");
>
> InitialContext ctx = new InitialContext(p);
>
> TestRemote myBean = (TestRemote) ctx.lookup("TestBeanRemote");
> String info = myBean.getInfo();
>
> When I run the code I get an: Exception in thread "main"
> javax.ejb.EJBAccessException: Unauthorized Access by Principal Denied
>
> So, I remove the security definitions from the EJB and it's deploy
> plan, the method executes, and the Principal it returns is
> UnauthenticatedPrincipal.
>
> KMSRealm is a server wide SQLLoginModule realm defined in the
> geronimo console. I know the login works, because changing the
> InitialContext credentials causes the login to fail. So all this
> works.
>
> I am basically trying to login via EJB, and then be able to do two
> things (1) define authorizations on the EJBs/methods (2) Retrieve
> the Subject/Principal. Both of these are very important.
>
> You need to map the prinicpal from the login module to the roles in
> your app, in your <security> element. Can you show what you have
> for this?
>
>
>
>
> I've also tried replacing my <security> element in the deploy plan
> to this:
> <security>
> <default-subject>
> <realm>KMSRealm</realm>
> <id>quintin</id>
> </default-subject>>
> </security>
>
> If you use something like this you also need to set up a credential
> store that will log into your realm to get the Subject you are
> trying to specify here.
>
>
>
> But then I get the following when deploying:
> Error: Operation failed: start of kms/KMSPlatform-ejb/1.0/jar
> failed
>
> Unknown start exception
>
> Configuration kms/KMSPlatform-ejb/1.0/jar failed to start
> due to
> the following reasons:
>
> The service
> EJBModule=kms/KMSPlatform-ejb/1.0/
> jar
> ,J2EEApplication=null,j2eeType=StatelessSessionBean,name=PersonnelBean
> did not start because
> kms/KMSPlatform-ejb/1.0/jar?EJBModule=kms/KMSPlatform-ejb/1.0/
> jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
> did not start.
>
> The service
> EJBModule=kms/KMSPlatform-ejb/1.0/
> jar,J2EEApplication=null,j2eeType=StatelessSessionBean,name=TestBean
> did not start because
> kms/KMSPlatform-ejb/1.0/jar?EJBModule=kms/KMSPlatform-ejb/1.0/
> jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
> did not start.
>
> The service
> EJBModule=kms/KMSPlatform-ejb/1.0/
> jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
> did not start because Unknown realm: KMSRealm
>
> I am up to my head in frustration. I gave Geronimo a try on a redev
> of a project, but what took me about half a day to setup on
> Glassfish has now taken me a week. Can anyone please help me out,
> because I really want to have Geronimo's benefits in my applications.
>
> i have to run now, if these hints don't get you farther let us know
> and I'll try to be more detailed. I think there is some
> documentation at least in the 2.2 docs for both of these. If they
> are hard to find and you can think of better ways to get to them
> please let us know.
>
> thanks
> david jencks
>
> --
> Quintin Beukes
>
>
>
>
> --
> Quintin Beukes
Re: Login Contexts NOT working
Posted by Quintin Beukes <qu...@skywalk.co.za>.
Hey David,
Thanks for the response. The community for Geronimo seems very small, so
it's quite a lonely struggle.
Either way. I finally got it right about 5 minutes ago, but yet again have
another problem. This isn't so much as a problem as it is an unreachable
feature.
Assume I get the IC as follows:
Properties p = new Properties();
p.put("java.naming.factory.initial",
"org.apache.openejb.client.RemoteInitialContextFactory");
p.put("java.naming.provider.url", "ejbd://localhost:4201");
// user and pass optional
p.put("openejb.authentication.realmName", "KMSRealm");
p.put("java.naming.security.principal", "quintin");
p.put("java.naming.security.credentials", "pass");
InitialContext ctx = new InitialContext(p);
I am able to login and have the method authorizations work as intended for
different users. The problem is that I use JAAS for the login and would like
to use my own LoginModule. Is there anyway to have the above method use JAAS
authentication with my own LoginModule?
Re. documentation, they are quite hard to find. They document the features
but it's not always clear that a given document is what you're looking for.
I sometimes read something and realize that a certain part of it might help
me. I am, however, documenting my struggles on my blog, so hopefully people
with similar problems can find an exact explanation on solving it.
Further I also usually keep wikis for projects I use up to date, and submit
patches for things I change. So whenever I get all these things working and
back on track I will be contributing to the project, whether in
issues/features requests being reported, documentation/source patch
submissions or wiki updates.
Q
On Sat, Sep 5, 2009 at 6:55 PM, David Jencks <da...@yahoo.com> wrote:
>
> On Sep 5, 2009, at 8:40 AM, Quintin Beukes wrote:
>
> My oh my this week has given me headaches. I went through hundreds of
>> lines of code for both geronimo and OpenEJB, and I can't seem to figure out
>> why this isn't working. From what I've found on the internet it should work
>> (unless I'm missing something).
>>
>> OK. So I have this EJB:
>>
>> @Stateless
>> @DeclareRoles( { "Admin" })
>> @RolesAllowed( { "Admin" })
>> public class TestBean implements TestRemote, TestLocal
>> {
>> @Resource
>> private SessionContext sessionCtx;
>>
>> public String getInfo()
>> {
>> Principal p = sessionCtx.getCallerPrincipal();
>> StringBuilder sb = new StringBuilder();
>> sb.append("\n").append("Principal: " + p.getName() + " - type: " +
>> p.getClass().getCanonicalName());
>> return sb.toString();
>> }
>> }
>>
>> getInfo() is a Remote method.
>>
>> Then it's deploy plan contains:
>> <security doas-current-called="true" default-role="Admin">
>>
>> </security>
>>
>> And I do a remote lookup as follows:
>>
>> Properties p = new Properties();
>> p.put("java.naming.factory.initial",
>> "org.apache.openejb.client.RemoteInitialContextFactory");
>> p.put("java.naming.provider.url", "ejbd://localhost:4201");
>> // user and pass optional
>> p.put("openejb.authentication.realmName", "KMSRealm");
>> p.put("java.naming.security.principal", "quintin");
>> p.put("java.naming.security.credentials", "pass");
>>
>> InitialContext ctx = new InitialContext(p);
>>
>> TestRemote myBean = (TestRemote) ctx.lookup("TestBeanRemote");
>> String info = myBean.getInfo();
>>
>> When I run the code I get an: Exception in thread "main"
>> javax.ejb.EJBAccessException: Unauthorized Access by Principal Denied
>>
>> So, I remove the security definitions from the EJB and it's deploy plan,
>> the method executes, and the Principal it returns is
>> UnauthenticatedPrincipal.
>>
>> KMSRealm is a server wide SQLLoginModule realm defined in the geronimo
>> console. I know the login works, because changing the InitialContext
>> credentials causes the login to fail. So all this works.
>>
>> I am basically trying to login via EJB, and then be able to do two things
>> (1) define authorizations on the EJBs/methods (2) Retrieve the
>> Subject/Principal. Both of these are very important.
>>
>
> You need to map the prinicpal from the login module to the roles in your
> app, in your <security> element. Can you show what you have for this?
>
>
>
>> I've also tried replacing my <security> element in the deploy plan to
>> this:
>> <security>
>> <default-subject>
>> <realm>KMSRealm</realm>
>> <id>quintin</id>
>> </default-subject>>
>> </security>
>>
>
> If you use something like this you also need to set up a credential store
> that will log into your realm to get the Subject you are trying to specify
> here.
>
>
>> But then I get the following when deploying:
>> Error: Operation failed: start of kms/KMSPlatform-ejb/1.0/jar failed
>>
>> Unknown start exception
>>
>> Configuration kms/KMSPlatform-ejb/1.0/jar failed to start due
>> to
>> the following reasons:
>>
>> The service
>>
>> EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=StatelessSessionBean,name=PersonnelBean
>> did not start because
>>
>> kms/KMSPlatform-ejb/1.0/jar?EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
>> did not start.
>>
>> The service
>>
>> EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=StatelessSessionBean,name=TestBean
>> did not start because
>>
>> kms/KMSPlatform-ejb/1.0/jar?EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
>> did not start.
>>
>> The service
>>
>> EJBModule=kms/KMSPlatform-ejb/1.0/jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
>> did not start because Unknown realm: KMSRealm
>>
>> I am up to my head in frustration. I gave Geronimo a try on a redev of a
>> project, but what took me about half a day to setup on Glassfish has now
>> taken me a week. Can anyone please help me out, because I really want to
>> have Geronimo's benefits in my applications.
>>
>
> i have to run now, if these hints don't get you farther let us know and
> I'll try to be more detailed. I think there is some documentation at least
> in the 2.2 docs for both of these. If they are hard to find and you can
> think of better ways to get to them please let us know.
>
> thanks
> david jencks
>
> --
>> Quintin Beukes
>>
>
>
--
Quintin Beukes
Re: Login Contexts NOT working
Posted by David Jencks <da...@yahoo.com>.
On Sep 5, 2009, at 8:40 AM, Quintin Beukes wrote:
> My oh my this week has given me headaches. I went through hundreds
> of lines of code for both geronimo and OpenEJB, and I can't seem to
> figure out why this isn't working. From what I've found on the
> internet it should work (unless I'm missing something).
>
> OK. So I have this EJB:
>
> @Stateless
> @DeclareRoles( { "Admin" })
> @RolesAllowed( { "Admin" })
> public class TestBean implements TestRemote, TestLocal
> {
> @Resource
> private SessionContext sessionCtx;
>
> public String getInfo()
> {
> Principal p = sessionCtx.getCallerPrincipal();
> StringBuilder sb = new StringBuilder();
> sb.append("\n").append("Principal: " + p.getName() + " - type: "
> + p.getClass().getCanonicalName());
> return sb.toString();
> }
> }
>
> getInfo() is a Remote method.
>
> Then it's deploy plan contains:
> <security doas-current-called="true" default-role="Admin">
>
> </security>
>
> And I do a remote lookup as follows:
>
> Properties p = new Properties();
> p.put("java.naming.factory.initial",
> "org.apache.openejb.client.RemoteInitialContextFactory");
> p.put("java.naming.provider.url", "ejbd://localhost:4201");
> // user and pass optional
> p.put("openejb.authentication.realmName", "KMSRealm");
> p.put("java.naming.security.principal", "quintin");
> p.put("java.naming.security.credentials", "pass");
>
> InitialContext ctx = new InitialContext(p);
>
> TestRemote myBean = (TestRemote) ctx.lookup("TestBeanRemote");
> String info = myBean.getInfo();
>
> When I run the code I get an: Exception in thread "main"
> javax.ejb.EJBAccessException: Unauthorized Access by Principal Denied
>
> So, I remove the security definitions from the EJB and it's deploy
> plan, the method executes, and the Principal it returns is
> UnauthenticatedPrincipal.
>
> KMSRealm is a server wide SQLLoginModule realm defined in the
> geronimo console. I know the login works, because changing the
> InitialContext credentials causes the login to fail. So all this
> works.
>
> I am basically trying to login via EJB, and then be able to do two
> things (1) define authorizations on the EJBs/methods (2) Retrieve
> the Subject/Principal. Both of these are very important.
You need to map the prinicpal from the login module to the roles in
your app, in your <security> element. Can you show what you have for
this?
>
> I've also tried replacing my <security> element in the deploy plan
> to this:
> <security>
> <default-subject>
> <realm>KMSRealm</realm>
> <id>quintin</id>
> </default-subject>>
> </security>
If you use something like this you also need to set up a credential
store that will log into your realm to get the Subject you are trying
to specify here.
>
> But then I get the following when deploying:
> Error: Operation failed: start of kms/KMSPlatform-ejb/1.0/jar
> failed
>
> Unknown start exception
>
> Configuration kms/KMSPlatform-ejb/1.0/jar failed to
> start due to
> the following reasons:
>
> The service
> EJBModule=kms/KMSPlatform-ejb/1.0/
> jar
> ,J2EEApplication=null,j2eeType=StatelessSessionBean,name=PersonnelBean
> did not start because
> kms/KMSPlatform-ejb/1.0/jar?EJBModule=kms/KMSPlatform-ejb/1.0/
> jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
> did not start.
>
> The service
> EJBModule=kms/KMSPlatform-ejb/1.0/
> jar,J2EEApplication=null,j2eeType=StatelessSessionBean,name=TestBean
> did not start because
> kms/KMSPlatform-ejb/1.0/jar?EJBModule=kms/KMSPlatform-ejb/1.0/
> jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
> did not start.
>
> The service
> EJBModule=kms/KMSPlatform-ejb/1.0/
> jar,J2EEApplication=null,j2eeType=JACCManager,name=JACCManager
> did not start because Unknown realm: KMSRealm
>
> I am up to my head in frustration. I gave Geronimo a try on a redev
> of a project, but what took me about half a day to setup on
> Glassfish has now taken me a week. Can anyone please help me out,
> because I really want to have Geronimo's benefits in my applications.
i have to run now, if these hints don't get you farther let us know
and I'll try to be more detailed. I think there is some documentation
at least in the 2.2 docs for both of these. If they are hard to find
and you can think of better ways to get to them please let us know.
thanks
david jencks
> --
> Quintin Beukes