geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quintin Beukes <quin...@skywalk.co.za>
Subject Re: Login Contexts NOT working
Date Sun, 06 Sep 2009 11:18:56 GMT
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 <quintin@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 <david_jencks@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 <david_jencks@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

Mime
View raw message