Skip to main content

@RunAs doesn't forward security principal?

10 replies [Last post]
Anonymous

We need to run a servlet that is not secured in any way (public
service).
The servlet needs to access session bean X (local interface, same EAR)
that also is not secured but marked as @RunAs("User")
That session bean X needs to access another session bean (local
interface, same EAR) Y which IS secured by @RolesAllowed("User").

At runtime, when SB X calls SB Y, GlassFish says that we do not have
access rights to execute the business method of SB Y.

We do not understand that, because SB X is marked with @RunAs, so we
expect propagation of access rights of this role.

GF: v2ur1
JDK: 6

We have no idea why that is not working.

Any ideas how to solve that?

(server.log is attached so you can see the full stack trace)

Thanks!
Markus
[Markus KARG.vcf]
[server.log]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
V B Kumar Jayanti

Markus Karg wrote:

>We need to run a servlet that is not secured in any way (public
>service).
>The servlet needs to access session bean X (local interface, same EAR)
>that also is not secured but marked as @RunAs("User")
>That session bean X needs to access another session bean (local
>interface, same EAR) Y which IS secured by @RolesAllowed("User").
>
>At runtime, when SB X calls SB Y, GlassFish says that we do not have
>access rights to execute the business method of SB Y.
>
>We do not understand that, because SB X is marked with @RunAs, so we
>expect propagation of access rights of this role.
>
>
It appears there is no mapping for the role "User" defined in your app
?. Can you add a run-as principal for SB X in sun-ejb-jar.xml and see.

Do you see a message of the following form during deployment :

"DL8019: The run-as principal User was assigned by the deployment system based on the specified role. Please consider defining an explicit run-as principal in the sun-specific deployment descriptor."

See :
http://java.sun.com/mailers/techtips/enterprise/2007/TechTips_March07.ht...

> You need to define the mapping for each role used in the application.
> For the role in |@RunAs|, if no principal is defined in
> |sun-ejb-jar.xml|, the application server uses a principal from the
> |security-role-mapping|. Here is an example that defines in the
> |sun-ejb-jar.xml| file the |run-as| principal for the |HelloEjb|
> enterprise bean:
>
> | |
> | |
> | |
> | HelloEjb|
> |
|
> | aprincipal|
> |
|
> |
|
> |
|
> |
|

Thanks.

>GF: v2ur1
>JDK: 6
>
>We have no idea why that is not working.
>
>Any ideas how to solve that?
>
>(server.log is attached so you can see the full stack trace)
>
>Thanks!
>Markus
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

[att1.html]

mkarg
Offline
Joined: 2007-12-09

We did what you proposed:

> > | |
> > | |
> > | |
> > | HelloEjb|
> > |
|
> > | aprincipal|
> > |
|
> > |
|
> > |
|
> > |
|



ComplaintServiceBean

cde


But still in server.log it says we're not authorized (but it prints the user 'cde' in the error message -- and that user [b]is[/b] authorized since he is in the sole defined group that is mapped upon the sole defined role -- the role needed by the called SB!):

[i](principals com.sun.enterprise.deployment.PrincipalImpl "cde")[/i]

The funny thing is, if we do not use @RunAs, and if we do not use the above sun-ejb-jar.xml, but just login to our servlet using simple BasicHttpAuthentication [b]with exactly the same principal name[/b] then it works pretty well.

So in short: Forwarding a manually Basic-Authenticated user works well, while @RunAs plus declared principal does not -- with the same user! For us that looks like a bug!

(see attached server.log!)

We're totally confused. It just seems as it completely ignores this entry in sun-ejb-jar! :-(

Please Help! :-)

Thanks
Markus

Markus Karg

Side Note: We changed both Session Beans from @RolesAllowed("User") to @PermitAll, but still it says we are not authorized! VERY strange!

Anybody an idea?

Thanks
Markus

-----Original Message-----
From: glassfish@javadesktop.org [mailto:glassfish@javadesktop.org]
Sent: Donnerstag, 10. Juli 2008 15:32
To: users@glassfish.dev.java.net
Subject: Re: @RunAs doesn't forward security principal?

We did what you proposed:

> > | |
> > | |
> > | |
> > | HelloEjb|
> > |
|
> > | aprincipal|
> > |
|
> > |
|
> > |
|
> > |
|



ComplaintServiceBean

cde


But still in server.log it says we're not authorized (but it prints the user 'cde' in the error message -- and that user [b]is[/b] authorized since he is in the sole defined group that is mapped upon the sole defined role -- the role needed by the called SB!):

[i](principals com.sun.enterprise.deployment.PrincipalImpl "cde")[/i]

The funny thing is, if we do not use @RunAs, and if we do not use the above sun-ejb-jar.xml, but just login to our servlet using simple BasicHttpAuthentication [b]with exactly the same principal name[/b] then it works pretty well.

So in short: Forwarding a manually Basic-Authenticated user works well, while @RunAs plus declared principal does not -- with the same user! For us that looks like a bug!

(see attached server.log!)

We're totally confused. It just seems as it completely ignores this entry in sun-ejb-jar! :-(

Please Help! :-)

Thanks
Markus
[Message sent by forum member 'mkarg' (mkarg)]

http://forums.java.net/jive/thread.jspa?messageID=285659

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

kumarjayanti
Offline
Joined: 2003-12-10

> Side Note: We changed both Session Beans from
> @RolesAllowed("User") to @PermitAll, but still it
> says we are not authorized! VERY strange!
>
> Anybody an idea?
Not sure about this. But in general when you specify a run-as principal then you also need to make sure that the principal is mapped to the specified role that appears in the @RolesAllowed annotation. Did you do that ?.

kumarjayanti
Offline
Joined: 2003-12-10

Just to clarify, you mentioned that you configured the following :



ComplaintServiceBean

cde


But still in server.log it says we're not authorized (but it prints the user 'cde' in the error message -- and that user is authorized since he is in the sole defined group that is mapped upon the sole defined role -- the role needed by the called SB!):

Since there is no real authentication happening so the assignment of groups in the Authorization Credentials will not happen (IMO). So please explicitly map principal cde to the role "User" inside your sun-ejb-jar.xml


User

cde cde

And let me know if that worked.

Markus Karg

Thank you for this tip. It works pretty well. :-)

But we do not understand what is going on. Because:

We already had all those entries, but in sun-application.xml we just had


User
QUIPSY_User

and the user "cde" was mapped to group QUIPSY_User in GlassFish's admin console (file realm).

So why do we now additionally need

cde

???

I mean, in sun-ejb-jar.xml the principal is already given, and GlassFish knows the roles / groups already. So why do we have to add that principal again in the security-role-mapping?

Can anybody explain this?

Thanks
Markus

-----Original Message-----
From: glassfish@javadesktop.org [mailto:glassfish@javadesktop.org]
Sent: Donnerstag, 17. Juli 2008 13:59
To: users@glassfish.dev.java.net
Subject: Re: RE: Re: @RunAs doesn't forward security principal?

Just to clarify, you mentioned that you configured the following :



ComplaintServiceBean

cde


But still in server.log it says we're not authorized (but it prints the user 'cde' in the error message -- and that user is authorized since he is in the sole defined group that is mapped upon the sole defined role -- the role needed by the called SB!):

Since there is no real authentication happening so the assignment of groups in the Authorization Credentials will not happen (IMO). So please explicitly map principal cde to the role "User" inside your sun-ejb-jar.xml


User

cde cde

And let me know if that worked.
[Message sent by forum member 'kumarjayanti' (kumarjayanti)]

http://forums.java.net/jive/thread.jspa?messageID=287278

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

V B Kumar Jayanti

Markus Karg wrote:

>Thank you for this tip. It works pretty well. :-)
>
>But we do not understand what is going on. Because:
>
>We already had all those entries, but in sun-application.xml we just had
>
>
> User
> QUIPSY_User
>

>
>and the user "cde" was mapped to group QUIPSY_User in GlassFish's admin console (file realm).
>
>So why do we now additionally need
>
>
cde >
>
>???
>
>I mean, in sun-ejb-jar.xml the principal is already given, and GlassFish knows the roles / groups already. So why do we have to add that principal again in the security-role-mapping?
>
>Can anybody explain this?
>
>
>
So how does glassfish know which realm to look for ?. Where did you
configure file-realm or any other realm in your application ?. Also no
authentication really takes place in this scenario since a run-as
principal has been specified. Normally if there was a Realm
Authentication then the groups would also get assigned. The
authorization system then tries to see if the principal is in an allowed
role.

Thanks.

>Thanks
>Markus
>
>-----Original Message-----
>From: glassfish@javadesktop.org [mailto:glassfish@javadesktop.org]
>Sent: Donnerstag, 17. Juli 2008 13:59
>To: users@glassfish.dev.java.net
>Subject: Re: RE: Re: @RunAs doesn't forward security principal?
>
>Just to clarify, you mentioned that you configured the following :
>
>
>
>
>ComplaintServiceBean
>
>cde
>
>

>
>

>
>But still in server.log it says we're not authorized (but it prints the user 'cde' in the error message -- and that user is authorized since he is in the sole defined group that is mapped upon the sole defined role -- the role needed by the called SB!):
>
>Since there is no real authentication happening so the assignment of groups in the Authorization Credentials will not happen (IMO). So please explicitly map principal cde to the role "User" inside your sun-ejb-jar.xml
>
>
>User
>
cde >cde
>

>
>And let me know if that worked.
>[Message sent by forum member 'kumarjayanti' (kumarjayanti)]
>
>http://forums.java.net/jive/thread.jspa?messageID=287278
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Markus Karg

>So how does glassfish know which realm to look for ?. Where did you
>configure file-realm or any other realm in your application ?.

We did not explicitly specify a realm because filerealm is the default.

Will it work if we declare a realm manually for our application (how to do that)?

>Also no
>authentication really takes place in this scenario since a run-as
>principal has been specified. Normally if there was a Realm
>Authentication then the groups would also get assigned. The
>authorization system then tries to see if the principal is in an allowed
>role.

Still I do not get the point, because:


ComplaintServiceBean

cde

with the above statement GlassFish knows the principal to use, and with the default realm it knows the realm to use, and in that realm it will find that "cde" is in group "User_Group", and from


User
QUIPSY_User

GlassFish knows that group "User_Group" obtains the role "User".

And "User" is what you must have to fulfil @RolesAllowed("User").

So all information IS GIVEN. No authentication is needed. Just a simple lookup in the default realm.

So why, from a conceptual aspect, does GlassFish not just look into that default realm to learn about the roles but instead forces admins to add the principal additionally to security-role-mapping? I just want to understand why the designers of GlassFish decided NOT to look into the realm to learn about the roles but to force people to give an ADDITIONAL (from my view: redundant) mapping.

That is what I just do not understand.

Maybe I am just blind, but I do not see the reason.

Thanks
Markus

dcam
Offline
Joined: 2006-05-05

I had a similar problem with calling EJBs in one glassfish instance from another glassfish instance.

I believe that runas and my scenario both use the GSSUP logins in doGSSUPLogin method in http://kickjava.com/src/com/sun/enterprise/security/auth/LoginContextDri...

I've created a patch that fixes the problem for me, and it is added as an attachment to the glassfish bug linked at http://forums.java.net/jive/thread.jspa?threadID=47148&tstart=0

monzillo
Offline
Joined: 2004-05-08

dcam, I thinkl I have alredy responded in another thread, but just to make sure.. we are working to integrate the fix for this in glassfish V3, and have recommended that it also be fixed in V2.

Marcus, the problem is the result of an oversight in the processing of identity assertions that are sent to a remote EJB container. In this case, there is a standard that defines the format of the identity assertion such that it includes just the caller (principal identity). Thus the additional group principals (re)assigned to the caller must be assigned at the remote node, and since this is an identity assertion (without an authenticator), the interaction with the underlying realm does not occur and the group principals are thus not restored. The solution is to interact with the realm to obtain the groups (after determining that the identity assertion is to be accepted).

Ron