SecurityAssociation is empty after successful login.
by alfonz19
Hi,
I got cornered while trying to do some basic authentization/authorization.
I've got here two applications - prototype war (working), real ear
application (not working). While looking for error, I've set both of them to
use SAME application policy in login-config.xml. Authentization succed in
both of them, but SecurityAssociation.getSubject returns null in ear app for
some reason. I've tried to fiddle a little with
"org.jboss.security.SecurityAssociation.ThreadLocal" property, but nothing
changed. Jbosssx client library is packaged in both war and ear(here it is
localed in nested .war) archive. In web.xml there are no roles
defined/requested - any authenticated user is authorized to do anything. So
where can be the problem? I'm out of ideas. Thanks in advance for any help
or hint.
martin.
-------- MORE DETAILS--------------
.war app: index.jsp content - some ugly testing code written in scriptlet.
After loggin in, user login is printed out and all associate roles are
listed out:
<%
String loggedUser = request.getRemoteUser();
if (loggedUser == null) {
out.println("No user is currently logged.<br/>");
} else {
out.println("currently logged-in user is: \""+
loggedUser+"\" \"./private/logOut.jsp\" logout <br/>");
out.println("associated principals are: <br/><ul>");
Subject subject = SecurityAssociation.getSubject();
for (Object principal : subject.getPrincipals()) {
out.println("<li>"+principal+" (represented
by "+principal.getClass()+")</li><br/>");
}
out.println("</ul>");
}
%>
----------------
.ear app: index.jsp content - some ugly testing code written in scriptlet.
After loggin in, user login is printed out, is confirmed that authorization
proces succeded (tested via isUserInRole method), but
SecurityAssociation.getSubject() returns null although.
<%
out.println("user: "+request.getRemoteUser()+"<br/>");
Subject subject = SecurityAssociation.getSubject();
out.println("is user in role A: "+request.isUserInRole("A")+"<br/>");
out.println("org.jboss.security.SecurityAssociation.ThreadLocal is
"+System.getProperty("org.jboss.security.SecurityAssociation.ThreadLocal")+"<br/>");
if (subject != null) {
for (Object principal : subject.getPrincipals()) {
out.println("<li>"+principal+" (represented by
"+principal.getClass()+")</li><br/>");
}
} else {
out.println("subject is null");
}
out.println("</ul>");
%>
--
View this message in context: http://www.nabble.com/SecurityAssociation-is-empty-after-successful-login...
Sent from the JBoss - Dev mailing list archive at Nabble.com.
14 years, 12 months
jboss-dev-forums emails
by Scott Stark
I'm not seeing the usual jboss-dev-forums emails for new postings.
Anyone know if this is something still being worked on?
14 years, 12 months
Re: [jboss-dev] embedded jopr console in which configs?
by Charles Crouch
Correct, it should only be in default and all.
I just checked the hudson build from r87817 and its still in all three.
Jason, can you zap it out of standard?
Thanks
Charles
----- "Dimitris Andreadis" <dandread(a)redhat.com> wrote:
> As it is now it's in 'standard', 'default', 'all'.
>
> I'd thought we would only include it in 'default' and 'all' ?
>
> /D
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
14 years, 12 months
Re: [jboss-dev] embedded jopr console in which configs?
by Charles Crouch
Right now its only in "default" and "all" in order to not overly increase the size of the JBAS distribution. [The console is around 10mb in size, mostly Seam and richfaces].
It may be possible to include it in other configs out of the box if a reasonable jar sharing scheme is implemented, however right now its up to the user to copy the console to other configs. One other reason that its not in "web" is that we've not tested it in that config.
There is no reason I can think of off the top of my head why the console shouldn't run in the "web" profile, since it doesnt utilize EJBs. If you can run regular Seam apps, the console should be fine, if you try it and hit problems please raise a jira in https://jira.jboss.org/jira/browse/EMBJOPR
Thanks
Charles
----- "Jaikiran Pai" <jpai(a)redhat.com> wrote:
> Any specific reason, we want to limit it to "default" and "all"? By
> the
> way, does the admin-console functionality in AS5 rely on the server
> configuration having EJB support? I was thinking whether end users can
>
> use the admin-console within a "web" server configuration (which does
>
> not have EJB support).
>
> -Jaikiran
> Dimitris Andreadis wrote:
> > As it is now it's in 'standard', 'default', 'all'.
> >
> > I'd thought we would only include it in 'default' and 'all' ?
> >
> > /D
> > _______________________________________________
> > jboss-development mailing list
> > jboss-development(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-development
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
14 years, 12 months
Jboss -4.0.5.GA and Solaris 10 and file download issues
by Jane Doe
We are having problems on a Jboss -4.0.5.GA Solaris 10 box where files are only partially downloading. We have tried various file types and all hang at approx. around 111KB. This issue is inconsistent and if we refresh a page or the download it will eventually work.
Any troubleshooting ideas would be appreciated.
span.widgetWrapper { font-size:1em; color:#B11196; text-decoration:underline; } a.widgetLink { color:#000000; text-decoration:none; } span.widgetInLink:hover { background-color:#B11196; }
14 years, 12 months
Bind interfaces coming from ServiceBindingManager
by Brian Stansberry
I think the binding interface for services that open sockets should be
coming from the ServiceBindingManager, same as the ports do. Currently
most services use ${jboss.bind.address} to inject the address directly
into the consuming service. But that precludes a management tool using
SBM as a central configuration point for all address/port usage in the
server.[1] Currently it's mostly only useful for the ports; if admins
wanted to use something other than ${jboss.bind.address} for a
particular service they'd have to go elsewhere in the tool to configure
that.
Thoughts?
[1] See my comment on https://jira.jboss.org/jira/browse/JOPR-159
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
14 years, 12 months
