Hi,
On Thu, Jan 7, 2016 at 3:51 PM, Sony Abraham <sony.abraham(a)ibsplc.com>
wrote:
Hi Arjan,
Thanks again for your support and guidance.
I have put my SAM module (jar) inside ear/lib.
If the SAM resides within the application then modifying standalone.xml is
not needed. A reference to a SAM in standalone.xml is only really needed if
the SAM is separate from the application, e.g. resides in a jar that you
put somewhere in the /modules folder of WildFly.
In this case you can just as well use the programmatic registration via a
listener as demonstrated by the samples.
Also I am facing the below issues, when I try to access a protected
resource, I want redirect to my login page. For this I have mentioned the
login.jsp in the web.xml as below
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/login.jsp</form-error-page>
</form-login-config>
</login-config>
But this is not happening automatically, I had to explicitly do
response.sendRedirect to get my login page (otherwise “Unauthorized” error
was coming). Is this the right thing to do ?
This is unfortunately not correct. A SAM is an authenticated mechanism, not
an identity store. So it replaces FORM. In other words the
entire login-config element can be removed here as its overridden when
using a SAM.
After I provide my username / password and do j_security_check I am
getting below error. Can you please let me know what I would had done wrong
j_security_check is the name in the URL that the build-in FORM
authentication mechanism happens to be listening to. j_security_check is
not some general mechanism by which security in Java EE is activated.
There is clearly a mismatch in Java EE security. There are build-in
authentication mechanisms and a standard API for custom authentication
mechanisms, but no standard API for the identity store (the artifact that
only focuses on {credentials in, caller data out}).
What's typical though here is building a SAM that only redirects to a login
page when a protected resource is requested and the user is not
authenticated, and otherwise relies on Servlet's programmatic authenticate
feature. So on /login.jsp you don't postback to a special URL, but post
back to /login.jsp. Then backing code of /login.jsp sets the credentials as
a request attribute and then calls HttpServletRequest.authenticate(). The
SAM can then do the authentication as shown in the samples.
Another option would be to re-use an existing authentication module that
implements FORM and then modify the part where it calls to the server
specific identity store. See e.g.
https://github.com/eclipse/jetty.project/blob/master/jetty-jaspi/src/main...
of
http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/...
(do take the license into account of these and take note that you may have
to do your own scrutiny of how secure those are)
If you absolutely want or need to use the existing build-in FORM, then
unfortunately JASPIC would not be the best option here. Unfortunately
setting up (custom) security in Java EE is currently not entirely trivial.
Kind regards,
Arjan Tijms
*HTTP method POST is not supported by this URL*
Regards
Sony
*From:* arjan tijms [mailto:arjan.tijms@gmail.com]
*Sent:* 07 January 2016 18:29
*To:* Sony Abraham
*Subject:* Re: [undertow-dev] Multiple logins under same user id in
Wildfly 9.0.2 uses same subject
Hi,
On Thu, Jan 7, 2016 at 8:10 AM, Sony Abraham <sony.abraham(a)ibsplc.com>
wrote:
Thank you for your reply. I am complete new to SAMPIC, do you have any
sample implementation for custom JASPIC on wildfly that I can refer to ?
Yes, there about 12 categories of samples for JASPIC here:
https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
The simplest sample can be found in
https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic/basi...
A very basic but fully working standalone application can be found here:
https://github.com/arjantijms/mechanism-to-store
I read though your blog
http://arjan-tijms.omnifaces.org/2012/11/implementing-container-authentic...
and
http://arjan-tijms.omnifaces.org/2013/04/whats-new-in-java-ee-7s-authenti...
, but configuring the SAM module alone in standalone.xml and mentioning
that in jboss-web.xml invoked my login module. Could not exactly understand
why the factory and context classes were required ( I assume those
implementations are provided by jboss itself)
The factory/config/context classes are there for when a fully in-app
portable application archive is needed. The only standardised way to
register a SAM is the programmatic way. The initial factory doesn't have a
method that just takes a SAM, but instead wants all these wrapper classes.
In hindsight this was perhaps not the most ideal decision and we hope to be
able to rectify this in the Java EE security EG.
The non-standard way, in this case the JBoss specific way via
standalone.xml, does accept just a SAM. In that case the wrappers are
indeed provided by JBoss.
But it’s been invoked for all resources (even non secure resources)
That's correct. JASPIC authentication modules are invoked for every
resource, both secured (protected) and non-secured (public). Authentication
is also not automatically tied to a session. Coming from some other
proprietary mechanisms this may seem controversial, but it actually makes
it really flexible and makes the creation of e.g. stateless header based
authentication mechanisms trivial. See e.g.
http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html
You can check whether the SAM *must* do authentication (which includes
being called for a secured resource) via a helper method such as:
public static boolean isProtectedResource(MessageInfo messageInfo) {
return Boolean.valueOf((String) messageInfo.getMap().get(IS_MANDATORY));
}
and the values in the handler and MessagePolicy are all coming as null.
That doesn't seem right. Perhaps this is a bug when registering a SAM via
the standalone.xml method. Where did you put
the com.test.TestServerAuthModule class? Is it inside a .jar that you put
in your WildFly install (and if so, where?), or is this class inside your
application archive (.war)?
Kind regards,
Arjan Tijms
How can I configure the container not to invoke the SAM for non-secure
resources and why is the handler and MessagePolicy coming as null ?
My standalone.xml entry is as below
<security-domain name="test" cache-type="default">
<authentication-jaspi>
<auth-module
code="com.test.TestServerAuthModule" flag="optional"/>
</authentication-jaspi>
</security-domain>
And jboss-web.xml as below
<jboss-web>
<security-domain>test</security-domain>
</jboss-web>
Regards,
Sony
*From:* arjan tijms [mailto:arjan.tijms@gmail.com]
*Sent:* 05 January 2016 23:03
*To:* Sony Abraham
*Cc:* undertow-dev(a)lists.jboss.org
*Subject:* Re: [undertow-dev] Multiple logins under same user id in
Wildfly 9.0.2 uses same subject
Hi,
I remember that in older versions of JBoss there always was a
(proprietary) API to explicitly clear the authentication cache. Maybe this
could be of help here if that API is still there.
An other option would be to try using the Java EE standard API for custom
authentication modules. This is called JASPIC and WildFly has excellent
support for those. Support is best in the latest version of WildFly, which
is 10cr5.
Kind regards,
Arjan Tijms
On Tue, Jan 5, 2016 at 9:18 AM, Sony Abraham <sony.abraham(a)ibsplc.com>
wrote:
Hi,
I am trying to port our existing application (in weblogic) to Jboss
wildfly.
Our application supports multiple logins under same user id but each
logins need to be treated in different security context. For this we invoke
the login modules by invoking j_security_check for each logins attempts. We
use a custome Jaas login module from where the subject is created with a
unique user token and set as name of the Principal after successful login.
But when using wildfly, the login module is invoked only the first time and
for the subsequent login attempts, the user subject is looked up from the
domain cache inside JBossCachedAuthenticationManager.
Further debugging into the issue i noticed below
1. After jaas login completes, the
org.wildfly.extension.undertow.security.AccountImpl in exchange of
ServletRequest gets updated with the new Principal (token set during jaas
login) and the OriginalPrincipal remains the same as the user id. This is
fine as expected (I hope).
2.
org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(final
AccountImpl account, final Object credential) uses the OriginalPrincipal to
send to authenticationManager for validation. Since this is not updated, it
will always be the original user id. Below source code from jboss.as
uses account.getPrincipal() for getting the incomingPrincipal. But this
is now changed to getOriginalPrincipal. I think this should be the
principal (not the OriginalPrincipal).
3. org.jboss.security.authentication.JBossCachedAuthenticationManager
caches the subject info against the OriginalPrincipal. Therefor it always
returns from the cache after the first successful authentication for a user
id and JAAS login module is never invoked after that. Shouldn't the caching
happen against the authenticated principal set in the subject
(CallerPrincipal).
Can anyone please let me know whether this behavior change is possible ?
Or is there any way I can configure custom class for
org.wildfly.extension.undertow.security.JAASIdentityManagerImpl and
org.jboss.security.authentication.JBossCachedAuthenticationManager in
wildfly 9.0.2.
Regards
Sony
DISCLAIMER: "The information in this e-mail and any attachment is
intended only for the person to whom it is addressed and may contain
confidential and/or privileged material. If you have received this e-mail
in error, kindly contact the sender and destroy all copies of the original
communication. IBS makes no warranty, express or implied, nor guarantees
the accuracy, adequacy or completeness of the information contained in this
email or any attachment and is not liable for any errors, defects,
omissions, viruses or for resultant loss or damage, if any, direct or
indirect."
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
DISCLAIMER: "The information in this e-mail and any attachment is
intended only for the person to whom it is addressed and may contain
confidential and/or privileged material. If you have received this e-mail
in error, kindly contact the sender and destroy all copies of the original
communication. IBS makes no warranty, express or implied, nor guarantees
the accuracy, adequacy or completeness of the information contained in this
email or any attachment and is not liable for any errors, defects,
omissions, viruses or for resultant loss or damage, if any, direct or
indirect."
DISCLAIMER: "The information in this e-mail and any attachment is
intended only for the person to whom it is addressed and may contain
confidential and/or privileged material. If you have received this e-mail
in error, kindly contact the sender and destroy all copies of the original
communication. IBS makes no warranty, express or implied, nor guarantees
the accuracy, adequacy or completeness of the information contained in this
email or any attachment and is not liable for any errors, defects,
omissions, viruses or for resultant loss or damage, if any, direct or
indirect."