You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by Kory Markevich <Ko...@ACL.com> on 2007/09/24 20:17:23 UTC
EJB Authentication Problem
I've been doing some research into using Geronimo 2.0.1 to host some
EJB3 session beans, interacting with a stand-alone client. I can
connect to the server and call methods fine, but I've encountered some
difficulties with security. Specifically I've tried using
Context.SECURITY_PRINCIPAL and Context.SECURITY_CREDENTIALS when
creating the InitialContext, but this seems to be broken. After some
tracing it seems that
org.apache.geronimo.openejb.GeronimoSecurityService.login( ) tries to
create a LoginContext with a null security realm, which throws an
exception and prevents authentication. I noticed that the latest
version of OpenEJB has added the key openejb.authentication.realmName,
but this is not available in 2.0.1 (and it seems a bit backward having
to have the client specify the security realm.)
I have been able to use
org.apache.openejb.client.ClientSecurity.directAuthentication( ) to
successfully authenticate, but it seems a bit hacky and is very OpenEJB
specific (and also requires the client to provide the realm name.)
Is there something I'm missing or doing wrong? I'm fairly new to EE
stuff so hopefully it's just some newbie mistake.
BTW, a couple other things I noticed:
- EJB security is disabled if the geronimo-application.xml doesn't at
least have an empty <security/> entry. This means any security
annotations are completely ignored, which surprised me.
- EJB3 EAR's will not deploy using the Eclipse plugin unless they
contain an application.xml file. Renaming the ZIP file to an EAR and
manually deploying works fine.
- When creating new EJB3 projects in Eclipse, all geronimo-*.xml files
reference the old schemas. If the schemas are changed to the 2.0.1
versions, then the editors fail (I'm assuming this is due to the EMF
JIRA entry?)
- When starting Eclipse, there are 3 warnings in the log compaining
about 'org.apache.geronimo.deployment.model' and
'org.apache.geronimo.v11.deployment.model'. I tried to disable the 1.0
and 1.1 features to get rid of the warnings (since I didn't need those
versions,) but then Geronimo 2.0 wouldn't be listed as an option when
creating new projects. The feature wasn't flagged as being broken
however.
________________________________
Kory Markevich
Tech Lead
ACL Services Ltd.
1550 Alberni Street | Vancouver | BC | V6G 1A5
Tel: 604 669 4225
Email: kory_markevich@acl.com | Web: www.acl.com
________________________________
The contents of this email are confidential and are for the intended
recipient(s) named above only. If you are not the intended recipient,
any copying, distribution or use of this email is prohibited. If you
have received this email in error, please notify the sender and delete
the email.
Re: EJB Authentication Problem
Posted by Kory Markevich <ko...@acl.com>.
Kevan Miller <ke...@...> writes:
> Kory,
> You can give the latest 2.0.2-SNAPSHOT build a try (http://
> people.apache.org/repo/m2-snapshot-repository/org/apache/geronimo/
> assemblies/geronimo-tomcat6-jee5/2.0.2-SNAPSHOT/geronimo-tomcat6-
> jee5-2.0.2-20070922.184612-1-bin.zip or similarly named jetty
> assembly). It contains a more recent build of OpenEJB.
>
> We're nearly ready for a new fix release...
>
> --kevan
Login via JNDI worked great, thanks. Looking forward to 2.0.2!
________________________________
Kory Markevich
Tech Lead
ACL Services Ltd.
1550 Alberni Street | Vancouver | BC | V6G 1A5
Tel: 604 669 4225
Email: kory_markevich@... | Web: www.acl.com
________________________________
The contents of this email are confidential and are for the intended
recipient(s) named above only. If you are not the intended recipient,
any copying, distribution or use of this email is prohibited. If you
have received this email in error, please notify the sender and delete
the email.
Re: EJB Authentication Problem
Posted by Kevan Miller <ke...@gmail.com>.
On Sep 24, 2007, at 6:48 PM, Kory Markevich wrote:
> David Jencks <da...@...> writes:
>
>> I think this is what you need to do. With openejb standalone the
>> login-by-getting-jndi might work better. We could fix it in geronimo
>> by having you supply a realm name
>
> I guess what I need to know is whether I'm missing something,
> because from what
> I can tell both login via JNDI and via JAAS (using
> org.apache.openejb.client.ClientLoginModule) from a stand-alone
> client cannot
> work in 2.0.1 because they both send null as the realm name, which
> Geronimo
> rejects. Both of these methods have changed in the latest OpenEJB
> to allow the
> realm name to be passed; any idea when those features or equivalent
> will end up
> in Geronimo?
Kory,
You can give the latest 2.0.2-SNAPSHOT build a try (http://
people.apache.org/repo/m2-snapshot-repository/org/apache/geronimo/
assemblies/geronimo-tomcat6-jee5/2.0.2-SNAPSHOT/geronimo-tomcat6-
jee5-2.0.2-20070922.184612-1-bin.zip or similarly named jetty
assembly). It contains a more recent build of OpenEJB.
We're nearly ready for a new fix release...
--kevan
Re: EJB Authentication Problem
Posted by Kory Markevich <ko...@acl.com>.
David Jencks <da...@...> writes:
> I think this is what you need to do. With openejb standalone the
> login-by-getting-jndi might work better. We could fix it in geronimo
> by having you supply a realm name
I guess what I need to know is whether I'm missing something, because from what
I can tell both login via JNDI and via JAAS (using
org.apache.openejb.client.ClientLoginModule) from a stand-alone client cannot
work in 2.0.1 because they both send null as the realm name, which Geronimo
rejects. Both of these methods have changed in the latest OpenEJB to allow the
realm name to be passed; any idea when those features or equivalent will end up
in Geronimo?
A workaround is to call ClientSecurity.directAuthorization myself and store the
returned identity. This *seems* to work fine, I just had hoped to be able to do
something a bit more standard.
> If you have a better idea I'm all ears. The problem I see with
> configuring the realm name in the server is that you are getting a
> global jndi tree containing all ejbs. I think we need to support
> each ejb app being deployed to a different security realm, but all of
> them accessing the ejbs through the same global jndi tree and network
> port. I haven't figured out how to resolve these conflicting needs
> without having the client supply the realm name it intends to use to
> log in.
I don't really have an issue with the realm name being supplied by the client
(and your use cases make sense,) it just surprised me that the server didn't
have default behaviour for the case when the realm wasn't passed. I had assumed
that something like this would be covered by the spec, but I'm inexperienced
with EE security.
> I think this is a bug. For web apps we won't deploy them if they
> have security in the spec dd but no geronimo security configured.
> Want to open a jira?
It's not an issue for me, so that would be up to you guys.
> Sorry I know nothing about eclipse.
No problem, I just wanted to let someone know about them.
Thanks for the help!
________________________________
Kory Markevich
Tech Lead
ACL Services Ltd.
1550 Alberni Street | Vancouver | BC | V6G 1A5
Tel: 604 669 4225
Email: kory_markevich@... | Web: www.acl.com
________________________________
The contents of this email are confidential and are for the intended
recipient(s) named above only. If you are not the intended recipient,
any copying, distribution or use of this email is prohibited. If you
have received this email in error, please notify the sender and delete
the email.
Re: EJB Authentication Problem
Posted by David Jencks <da...@yahoo.com>.
On Sep 24, 2007, at 2:17 PM, Kory Markevich wrote:
> I've been doing some research into using Geronimo 2.0.1 to host some
> EJB3 session beans, interacting with a stand-alone client. I can
> connect to the server and call methods fine, but I've encountered some
> difficulties with security. Specifically I've tried using
> Context.SECURITY_PRINCIPAL and Context.SECURITY_CREDENTIALS when
> creating the InitialContext, but this seems to be broken. After some
> tracing it seems that
> org.apache.geronimo.openejb.GeronimoSecurityService.login( ) tries to
> create a LoginContext with a null security realm, which throws an
> exception and prevents authentication. I noticed that the latest
> version of OpenEJB has added the key openejb.authentication.realmName,
> but this is not available in 2.0.1 (and it seems a bit backward having
> to have the client specify the security realm.)
>
> I have been able to use
> org.apache.openejb.client.ClientSecurity.directAuthentication( ) to
> successfully authenticate, but it seems a bit hacky and is very
> OpenEJB
> specific (and also requires the client to provide the realm name.)
>
> Is there something I'm missing or doing wrong? I'm fairly new to EE
> stuff so hopefully it's just some newbie mistake.
I think this is what you need to do. With openejb standalone the
login-by-getting-jndi might work better. We could fix it in geronimo
by having you supply a realm name :-)
If you have a better idea I'm all ears. The problem I see with
configuring the realm name in the server is that you are getting a
global jndi tree containing all ejbs. I think we need to support
each ejb app being deployed to a different security realm, but all of
them accessing the ejbs through the same global jndi tree and network
port. I haven't figured out how to resolve these conflicting needs
without having the client supply the realm name it intends to use to
log in.
>
> BTW, a couple other things I noticed:
>
> - EJB security is disabled if the geronimo-application.xml doesn't at
> least have an empty <security/> entry. This means any security
> annotations are completely ignored, which surprised me.
I think this is a bug. For web apps we won't deploy them if they
have security in the spec dd but no geronimo security configured.
Want to open a jira?
> - EJB3 EAR's will not deploy using the Eclipse plugin unless they
> contain an application.xml file. Renaming the ZIP file to an EAR and
> manually deploying works fine.
> - When creating new EJB3 projects in Eclipse, all geronimo-*.xml files
> reference the old schemas. If the schemas are changed to the 2.0.1
> versions, then the editors fail (I'm assuming this is due to the EMF
> JIRA entry?)
> - When starting Eclipse, there are 3 warnings in the log compaining
> about 'org.apache.geronimo.deployment.model' and
> 'org.apache.geronimo.v11.deployment.model'. I tried to disable the
> 1.0
> and 1.1 features to get rid of the warnings (since I didn't need those
> versions,) but then Geronimo 2.0 wouldn't be listed as an option when
> creating new projects. The feature wasn't flagged as being broken
> however.
Sorry I know nothing about eclipse.
thanks!
david jencks
>
> ________________________________
>
>
> Kory Markevich
> Tech Lead
> ACL Services Ltd.
>
> 1550 Alberni Street | Vancouver | BC | V6G 1A5
> Tel: 604 669 4225
> Email: kory_markevich@acl.com | Web: www.acl.com
>
> ________________________________
>
> The contents of this email are confidential and are for the intended
> recipient(s) named above only. If you are not the intended recipient,
> any copying, distribution or use of this email is prohibited. If you
> have received this email in error, please notify the sender and delete
> the email.
>
Re: EJB Authentication Problem
Posted by Tim McConnell <ti...@gmail.com>.
Hi Kory, it took me a while to find the Eclipse plugin error messages you
noticed. Are these below similar to the messages you're getting in your
workspaces\.metadata\.log file ??
!ENTRY org.eclipse.emf.ecore 2 0 2007-09-21 17:37:42.265
!MESSAGE Both 'org.apache.geronimo.deployment.model' and
'org.apache.geronimo.v11.deployment.model' register an extension parser for
'deployment'
!ENTRY org.eclipse.emf.ecore 2 0 2007-09-21 17:37:42.281
!MESSAGE Both 'org.apache.geronimo.deployment.model' and
'org.apache.geronimo.v11.deployment.model' register an extension parser for 'naming'
!ENTRY org.eclipse.emf.ecore 2 0 2007-09-21 17:37:42.281
!MESSAGE Both 'org.apache.geronimo.deployment.model' and
'org.apache.geronimo.v11.deployment.model' register an extension parser for 'web'
If so, they are benign although somewhat confusing. Unfortunately, and as you've
noticed, you cannot disable the features you don't need/want since all the
features are tightly coupled. However, we hope to improve that in subsequent
releases. Still, I shall open a JIRA to eliminate those warning messages. Thanks
much for the feedback.
Kory Markevich wrote:
> I've been doing some research into using Geronimo 2.0.1 to host some
> EJB3 session beans, interacting with a stand-alone client. I can
> connect to the server and call methods fine, but I've encountered some
> difficulties with security. Specifically I've tried using
> Context.SECURITY_PRINCIPAL and Context.SECURITY_CREDENTIALS when
> creating the InitialContext, but this seems to be broken. After some
> tracing it seems that
> org.apache.geronimo.openejb.GeronimoSecurityService.login( ) tries to
> create a LoginContext with a null security realm, which throws an
> exception and prevents authentication. I noticed that the latest
> version of OpenEJB has added the key openejb.authentication.realmName,
> but this is not available in 2.0.1 (and it seems a bit backward having
> to have the client specify the security realm.)
>
> I have been able to use
> org.apache.openejb.client.ClientSecurity.directAuthentication( ) to
> successfully authenticate, but it seems a bit hacky and is very OpenEJB
> specific (and also requires the client to provide the realm name.)
>
> Is there something I'm missing or doing wrong? I'm fairly new to EE
> stuff so hopefully it's just some newbie mistake.
>
> BTW, a couple other things I noticed:
>
> - EJB security is disabled if the geronimo-application.xml doesn't at
> least have an empty <security/> entry. This means any security
> annotations are completely ignored, which surprised me.
> - EJB3 EAR's will not deploy using the Eclipse plugin unless they
> contain an application.xml file. Renaming the ZIP file to an EAR and
> manually deploying works fine.
> - When creating new EJB3 projects in Eclipse, all geronimo-*.xml files
> reference the old schemas. If the schemas are changed to the 2.0.1
> versions, then the editors fail (I'm assuming this is due to the EMF
> JIRA entry?)
> - When starting Eclipse, there are 3 warnings in the log compaining
> about 'org.apache.geronimo.deployment.model' and
> 'org.apache.geronimo.v11.deployment.model'. I tried to disable the 1.0
> and 1.1 features to get rid of the warnings (since I didn't need those
> versions,) but then Geronimo 2.0 wouldn't be listed as an option when
> creating new projects. The feature wasn't flagged as being broken
> however.
>
> ________________________________
>
>
> Kory Markevich
> Tech Lead
> ACL Services Ltd.
>
> 1550 Alberni Street | Vancouver | BC | V6G 1A5
> Tel: 604 669 4225
> Email: kory_markevich@acl.com | Web: www.acl.com
>
> ________________________________
>
> The contents of this email are confidential and are for the intended
> recipient(s) named above only. If you are not the intended recipient,
> any copying, distribution or use of this email is prohibited. If you
> have received this email in error, please notify the sender and delete
> the email.
>
>
--
Thanks,
Tim McConnell