Approaches on security in JSF

My question is pretty broad, so I'm just looking for a general answer.
What is the standard (or most common) approach to authentication and authorization in JSF?
1) At one instance, some time ago, I was utilizing a simple declarative, form-based, container-managed login mechanism in Tomcat (with DataSource/JDBCRealm), but that made me do some acrobatics with redirections because the container did all the checks and never gave me a chance to grab the details typed by the user... so, in the end, it turned out to be more of a hack than an actual way to do security.
2) I also keep reading that people turn to Spring security (Acegi). This seems like a good idea, but it's hard to believe that JSF does not have it's own security mechanism.
3) JAAS also comes to mind, especially after seeing the JAASRealm implementation on Tomcat, but this is Tomcat specific and requires a self-implemented LoginModule and Principal...
4) I also see some third-party libraries like jGuard that seem pretty decent (first-look impression), but still, that's hardly the norm.
So I am at loss now, how is security "supposed" to be done is JSF? Is it usually vendor specific? Any insight will be greatly appreciated!

jadespirit wrote:
My question is pretty broad, so I'm just looking for a general answer.
What is the standard (or most common) approach to authentication and authorization in JSF?To start, authentication and authorization should not be tight coupled to JSF. JSF is just a component based MVC framework which can run on top of JSP/Servlet. Security is to be done at lower level, in the JSP/Servlet API.
1) At one instance, some time ago, I was utilizing a simple declarative, form-based, container-managed login mechanism in Tomcat (with DataSource/JDBCRealm), but that made me do some acrobatics with redirections because the container did all the checks and never gave me a chance to grab the details typed by the user... so, in the end, it turned out to be more of a hack than an actual way to do security.In JSF you can just get the underlying HttpServletRequest by ExternalContext#getRequest(), which on its turn provides methods to get details about the logged in user.
2) I also keep reading that people turn to Spring security (Acegi). This seems like a good idea, but it's hard to believe that JSF does not have it's own security mechanism.JSF is not comparable with Spring.
3) JAAS also comes to mind, especially after seeing the JAASRealm implementation on Tomcat, but this is Tomcat specific and requires a self-implemented LoginModule and Principal...Realm is not appserver specific.
4) I also see some third-party libraries like jGuard that seem pretty decent (first-look impression), but still, that's hardly the norm.No wording about this as I don't have experience with them.
So I am at loss now, how is security "supposed" to be done is JSF? Is it usually vendor specific? Any insight will be greatly appreciated!Realm is good. You can also decide to homegrow a simple one yourself. Have a database with users, have a loginbean which puts the logged in user in session, have a Filter which checks the logged in user. In JSF you can if necessary just use EL to access the logged in user in session.

Similar Messages

Arch approach to security

The recent kernel bug brought some forum posts because the distrowatch error about Arch. Distrowatch was wrong but there are some things that might keep security conscious people away from Arch:
- change logs. For example php 5.2.5-4 was released a few days ago. Why? Is there a critical bug-fix, so I should upgrade as soon as possible, or can I wait until my regular update schedule? (Otherwise php is a great package in arch, thanks Pierre)
- some packages are quickly updated, some not. See http://bugs.archlinux.org/task/8613 from 2007-11-20 to 2008-02-11 to apply some simple patches. Even 2007-11-20 was quite late. Is someone looking on others distros security changelogs or security sites to see what is happening around?
- the arch way, as vanilla as possible, config files as default as possible is not always the best approach. The denyhosts problem, the xorg default config listening on the net are two examples fixed as result of users requests, great, but they where obvious... One of the reasons php is great for me is because it is not quite the arch way, it is patched (Suhosin)
- since when is iptables 1.4.0 out? 2007-12-22. Not crucial, but again this raises the question "how much does Arch care about security?"
Not to mention Fedora/RedHat/Gentoo/OpenBSD (at least) usage of hardening gcc switches for theirs packages. These switches are in vanilla gcc since 2005. Fedora/RedHat also uses the vanilla kernel's selinux.
Last edited by VikM (2008-02-18 14:52:46)

Pudge wrote:If you want to discuss how fast important security fixes are made available, then you must take into account the reliability of our mirror sites. Especially when Arch Linux scolds you for using the Arch Linux mirror. At this point, Arch cannot afford the bandwidth for everyone to get their updates from the Arch server. Arch depends on the mirrors to continue to operate. If you want to question the Arch approach to security, then you need to back it up with donations that will allow Arch to afford the bandwidth necessary for the only mirror they have control over.
As guilty of writing some comments at DW you're free to through stones at me! Why do I do it? I don't know. Maybe too many tea time breaks. DW's comment section is a mine field so I probably do best in ignoring it.
Anyway, the synchronisation of mirrors can be an issue with many other distributions as well, even though their budget is bigger and maybe have corporation support. So would more money necessarily make all mirrors working faster?
The mirrors I use for Arch here in Sweden tend to be some few hours behind, but not more. I have no insight in how this is working, hence I'm asking since some mirrors obviously are quickly updated and as you say Pudge some are slower.
Another thought: even though wasting my time writing those comments at DW's, I at least think it contributed to that Ladislav explained his view on the topic. For him the main question is obviously not about whether updates are done or not in due time, but more about, as he says, whether a distribution conforms to the "real UNIX security infrastructure", and his understanding of this term is rigid. On the other hand I don't see any signs of Arch folks being overly interested in getting DW to advertise Arch, and why be? I'm confident that Arch will continue to develop positively, not that I can boost about being a long time Arch user, and details like this might eventually change or fall into its places as time goes by, thanks to its active developers and community.
Last edited by KimTjik (2008-02-20 17:08:35)

Using container managed form-based security in JSF

h1. Using container managed, form-based security in a JSF web app.
A Practical Solution
h2. {color:#993300}*But first, some background on the problem*{color}
The Form components available in JSF will not let you specify the target action, everything is a post-back. When using container security, however, you have to specifically submit to the magic action j_security_check to trigger authentication. This means that the only way to do this in a JSF page is to use an HTML form tag enclosed in verbatim tags. This has the side effect that the post is not handled by JSF at all meaning you can't take advantage of normal JSF functionality such as validators, plus you have a horrible chimera of a page containing both markup and components. This screws up things like skinning. ([credit to Duncan Mills in this 2 years old article|http://groundside.com/blog/DuncanMills.php?title=j2ee_security_a_jsf_based_login_form&more=1&c=1&tb=1&pb=1]).
In this solution, I will use a pure JSF page as the login page that the end user interacts with. This page will simply gather the input for the username and password and pass that on to a plain old jsp proxy to do the actual submit. This will avoid the whole problem of having to use verbatim tags or a mixture of JSF and JSP in the user view.
h2. {color:#993300}*Step 1: Configure the Security Realm in the Web App Container*{color}
What is a container? A container is basically a security framework that is implemented directly by whatever app server you are running, in my case Glassfish v2ur2 that comes with Netbeans 6.1. Your container can have multiple security realms. Each realm manages a definition of the security "*principles*" that are defined to interact with your application. A security principle is basically just a user of the system that is defined by three fields:
- Username
- Group
- Password
The security realm can be set up to authenticate using a simple file, or through JDBC, or LDAP, and more. In my case, I am using a "file" based realm. The users are statically defined directly through the app server interface. Here's how to do it (on Glassfish):
1. Start up your app server and log into the admin interface (http://localhost:4848)
2. Drill down into Configuration > Security > Realms.
3. Here you will see the default realms defined on the server. Drill down into the file realm.
4. There is no need to change any of the default settings. Click the Manage Users button.
5. Create a new user by entering username/password.
Note: If you enter a group name then you will be able to define permissions based on group in your app, which is much more usefull in a real app.
I entered a group named "Users" since my app will only have one set of permissions and all users should be authenticated and treated the same.
That way I will be able to set permissions to resources for the "Users" group that will apply to all users that have this group assigned.
TIP: After you get everything working, you can hook it all up to JDBC instead of "file" so that you can manage your users in a database.
h2. {color:#993300}*Step 2: Create the project*{color}
Since I'm a newbie to JSF, I am using Netbeans 6.1 so that I can play around with all of the fancy Visual Web JavaServer Faces components and the visual designer.
1. Start by creating a new Visual Web JSF project.
2. Next, create a new subfolder under your web root called "secure". This is the folder that we will define a Security Constraint for in a later step, so that any user trying to access any page in this folder will be redirected to a login page to sign in, if they haven't already.
h2. {color:#993300}*Step 3: Create the JSF and JSP files*{color}
In my very simple project I have 3 pages set up. Create the following files using the default templates in Netbeans 6.1:
1. login.jsp (A Visual Web JSF file)
2. loginproxy.jspx (A plain JSPX file)
3. secure/securepage.jsp (A Visual Web JSF file... Note that it is in the sub-folder named secure)
Code follows for each of the files:
h3. {color:#ff6600}*First we need to add a navigation rule to faces-config.xml:*{color}
    <navigation-rule>
<from-view-id>/login.jsp</from-view-id>
        <navigation-case>
<from-outcome>loginproxy</from-outcome>
<to-view-id>/loginproxy.jspx</to-view-id>
        </navigation-case>
    </navigation-rule>
NOTE: This navigation rule simply forwards the request to loginproxy.jspx whenever the user clicks the submit button. The button1_action() method below returns the "loginproxy" case to make this happen.
h3. {color:#ff6600}*login.jsp -- A very simple Visual Web JSF file with two input fields and a button:*{color}
<?xml version="1.0" encoding="UTF-8"?>
<jsp:root version="2.1"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:jsp="http://java.sun.com/JSP/Page"
xmlns:webuijsf="http://www.sun.com/webui/webuijsf">
    <jsp:directive.page
contentType="text/html;charset=UTF-8"
pageEncoding="UTF-8"/>
    <f:view>
        <webuijsf:page
id="page1">
<webuijsf:html id="html1">
<webuijsf:head id="head1">
<webuijsf:link id="link1"
url="/resources/stylesheet.css"/>
</webuijsf:head>
<webuijsf:body id="body1" style="-rave-layout: grid">
<webuijsf:form id="form1">
<webuijsf:textField binding="#{login.username}"
id="username" style="position: absolute; left: 216px; top:
96px"/>
<webuijsf:passwordField binding="#{login.password}" id="password"
style="left: 216px; top: 144px; position: absolute"/>
<webuijsf:button actionExpression="#{login.button1_action}"
id="button1" style="position: absolute; left: 216px; top:
216px" text="GO"/>
</webuijsf:form>
</webuijsf:body>
</webuijsf:html>
        </webuijsf:page>
    </f:view>
</jsp:root>h3. *login.java -- implent the
button1_action() method in the login.java backing bean*
    public String button1_action() {
        setValue("#{requestScope.username}",
(String)username.getValue());
setValue("#{requestScope.password}", (String)password.getValue());
        return "loginproxy";
    }h3. {color:#ff6600}*loginproxy.jspx -- a login proxy that the user never sees. The onload="document.forms[0].submit()" automatically submits the form as soon as it is rendered in the browser.*{color}
{code}
<?xml version="1.0" encoding="UTF-8"?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page"
version="2.0">
<jsp:output omit-xml-declaration="true" doctype-root-element="HTML"
doctype-system="http://www.w3.org/TR/html4/loose.dtd"
doctype-public="-W3CDTD HTML 4.01 Transitional//EN"/>
<jsp:directive.page contentType="text/html"
pageEncoding="UTF-8"/>
<html>
<head> <meta
http-equiv="Content-Type" content="text/html;
charset=UTF-8"/>
<title>Logging in...</title>
</head>
<body
onload="document.forms[0].submit()">
<form
action="j_security_check" method="POST">
<input type="hidden" name="j_username"
value="${requestScope.username}" />
<input type="hidden" name="j_password"
value="${requestScope.password}" />
</form>
</body>
</html>
</jsp:root>
{code}
h3. {color:#ff6600}*secure/securepage.jsp -- A simple JSF{color}
target page, placed in the secure folder to test access*
{code}
<?xml version="1.0" encoding="UTF-8"?>
<jsp:root version="2.1"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:webuijsf="http://www.sun.com/webui/webuijsf">
<jsp:directive.page
contentType="text/html;charset=UTF-8"
pageEncoding="UTF-8"/>
<f:view>
<webuijsf:page
id="page1">
<webuijsf:html id="html1">
<webuijsf:head id="head1">
<webuijsf:link id="link1"
url="/resources/stylesheet.css"/>
</webuijsf:head>
<webuijsf:body id="body1" style="-rave-layout: grid">
<webuijsf:form id="form1">
<webuijsf:staticText id="staticText1" style="position:
absolute; left: 168px; top: 144px" text="A Secure Page"/>
</webuijsf:form>
</webuijsf:body>
</webuijsf:html>
</webuijsf:page>
</f:view>
</jsp:root>
{code}
h2. {color:#993300}*_Step 4: Configure Declarative Security_*{color}
This type of security is called +declarative+ because it is not configured programatically. It is configured by declaring all of the relevant parameters in the configuration files: *web.xml* and *sun-web.xml*. Once you have it configured, the container (application server and java framework) already have the implementation to make everything work for you.
*web.xml will be used to define:*
- Type of security - We will be using "form based". The loginpage.jsp we created will be set as both the login and error page.
- Security Roles - The security role defined here will be mapped (in sun-web.xml) to users or groups.
- Security Constraints - A security constraint defines the resource(s) that is being secured, and which Roles are able to authenticate to them.
*sun-web.xml will be used to define:*
- This is where you map a Role to the Users or Groups that are allowed to use it.
+I know this is confusing the first time, but basically it works like this:+
*Security Constraint for a URL* -> mapped to -> *Role* -> mapped to -> *Users & Groups*
h3. {color:#ff6600}*web.xml -- here's the relevant section:*{color}
{code}
<security-constraint>
<display-name>SecurityConstraint</display-name>
<web-resource-collection>
<web-resource-name>SecurePages</web-resource-name>
<description/>
<url-pattern>/faces/secure/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>HEAD</http-method>
<http-method>PUT</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
<http-method>DELETE</http-method>
</web-resource-collection>
<auth-constraint>
<description/>
<role-name>User</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<realm-name/>
<form-login-config>
<form-login-page>/faces/login.jsp</form-login-page>
<form-error-page>/faces/login.jsp</form-error-page>
</form-login-config>
</login-config>
<security-role>
<description/>
<role-name>User</role-name>
</security-role>
{code}
h3. {color:#ff6600}*sun-web.xml -- here's the relevant section:*{color}
{code}
<security-role-mapping>
<role-name>User</role-name>
<group-name>Users</group-name>
</security-role-mapping>
{code}
h3. {color:#ff6600}*Almost done!!!*{color}
h2. {color:#993300}*_Step 5: A couple of minor "Gotcha's"_ *{color}
h3. {color:#ff6600}*_Gotcha #1_*{color}
You need to configure the "welcome page" in web.xml to point to faces/secure/securepage.jsp ... Note that there is *_no_* leading / ... If you put a / in there it will barf all over itself .
h3. {color:#ff6600}*_Gotcha #2_*{color}
Note that we set the <form-login-page> in web.xml to /faces/login.jsp ... Note the leading / ... This time, you NEED the leading slash, or the server will gag.
*DONE!!!*
h2. {color:#993300}*_Here's how it works:_*{color}
1. The user requests the a page from your context (http://localhost/MyLogin/)
2. The servlet forwards the request to the welcome page: faces/secure/securepage.jsp
3. faces/secure/securepage.jsp has a security constraint defined, so the servlet checks to see if the user is authenticated for the session.
4. Of course the user is not authenticated since this is the first request, so the servlet forwards the request to the login page we configured in web.xml (/faces/login.jsp).
5. The user enters username and password and clicks a button to submit.
6. The button's action method stores away the username and password in the request scope.
7. The button returns "loginproxy" navigation case which tells the navigation handler to forward the request to loginproxy.jspx
8. loginproxy.jspx renders a blank page to the user which has hidden username and password fields.
9. The hidden username and password fields grab the username and password variables from the request scope.
10. The loginproxy page is automatically submitted with the magic action "j_security_check"
11. j_security_check notifies the container that authentication needs to be intercepted and handled.
12. The container authenticates the user credentials.
13. If the credentials fail, the container forwards the request to the login.jsp page.
14. If the credentials pass, the container forwards the request to *+the last protected resource that was attempted.+*
+Note the last point! I don't know how, but no matter how many times you fail authentication, the container remembers the last page that triggered authentication and once you finally succeed the container forwards your request there!!!!+
+The user is now at the secure welcome page.+
If you have read this far, I thank you for your time, and I seriously question your ability to ration your time pragmatically.
Kerry Randolph

If you want login security on your web app, this is one way to do it. (the easiest way i have seen).
This method allows you to create a custom login form and error page using JSF.
The container handles the actual authentication and protection of the resources based on what you declare in web.xml and sun-web.xml.
This example uses a statically defined user/password, stored in a file, but you can also configure JDBC realm in Glassfish, so that that users can register for access and your program can store the username/passwrod in a database.
I'm new to programming, so none of this may be a good practice, or may not be secure at all.
I really don't know what I'm doing, but I'm learning, and this has been the easiest way that I have found to add authentication to a web app, without having to write the login modules yourself.
Another benefit, and I think this is key ***You don't have to include any extra code in the pages that you want to protect*** The container manages this for you, based on the constraints you declare in web.xml.
So basically you set it up to protect certain folders, then when any user tries to access pages in that folder, they are required to authenticate.
--Kerry

Best Approach for Security in WebCenter Portal Application

Hi,
We are analyzing a right approach for webcenter portal security on an application . We found that we can do all Roles and Security in Page Hierarchy which in turn stores the security details in Jazn-data.xml . Is this the right approach for defining the roles and security for a webcenter portal application .
What is the importance of Configuring WS_security in webcenter Portal Application and do we need to define this WS_Security even after defining them in page hierarchy. Could you please guide us on this .
Thank you,
Sashank P

Hi Shashank,
First sorry for late reply,
WS_Security, can you please explain what do you mean by WS_Security, from the term i could not infer which part you are talking about.
Let me tell you about the Webcenter security -
This is the heirarchy , the Fusion middelware forms the base with webcenter at the top.\
Webcenter Security
|
ADF Security
|
Fustion Midddleware Security (OPSS)
Now you are goin to apply security to your Webcenter and ADF layers.
Lets come back to the question .
Any webcenter portal, you have to use the Jazn-Data.xml file to secure all the content whether its the navigation /pages /admin pages/taskflows etc.
Its pretty much easy to use , let me know if you have any difficulty on that.
Page hierarchy -> Yes you have an option to set your security for pages alone, here you have addition fine grain permisions (update/delete/personalise etc).
If you need those fine grain permissions you can use this.
To Conclude i would say use jazn-data for taskflows/components/admin page protection etc.
Use Page heirarchy's fine grain permission to pages and navigation model's visible attribute to show/hide navigation based on user's roles.
Let me know if this helps

Security In JSF

hello,
i had a problem to how to maintain security in my web application(i'm using JSF).
some one advice me to use Acegi,others simple filter ...
any idea please how to perform security to my JSF web site?

Hi,
I think your question is too broad for us to answer. There many aspects that you have to consider when you are thinking about security in your own application, such as:
- what do you want to secure? access to URL? access to bean? combination of both?'
- What about authentication. do you want to use LDAP, or do you want to use database-based user auth?
and many more..
So it is all depends on the requirements. In any case, have you consider other alternatives like jsecurity (www.jsecurity.org)?

Security with jsf

Hello,
my website has 5 roles groups and each one can access to differents pages.
How can i forbid the access to pages of the role group 1 to the others?
In fact, a bean has a "level" variable which contain the role group of the user.
I would like to test this value and if it is the good one, give access.
Otherwise, i would like to redirect the user to the login page
Thx u in advance !
PS: All is made with JSF

Hi
Put this in Ur web.xml
<filter>
          <filter-name>SecurityFilter</filter-name>
          <filter-class>adjuvant.poa.util.SecurityFilter</filter-class>
     </filter>
     <filter-mapping>
          <filter-name>SecurityFilter</filter-name>
          <url-pattern>*.jsf</url-pattern>
     </filter-mapping>
here is ur security class
adjuvant.poa.util.SecurityFilter
* [email protected]
package adjuvant.poa.util;
import javax.servlet.Filter;
import javax.servlet.FilterConfig;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.FilterChain;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import java.io.IOException;
import java.util.Iterator;
import java.util.Set;
import java.util.HashSet;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import adjuvant.poa.jsf.backingbeans.UserBean;
* This Filter class handle the security of the application.
* <p>
* It should be configured inside the web.xml.
public class SecurityFilter implements Filter {
     //the login page uri
     private static final String LOGIN_PAGE_URI = "login.jsf";
     private static final String ADMIN_LOGIN_PAGE_URI = "../login.jsf";
     private static final String USER_BEAN = "nurse";
     //the logger object
     private Log logger = LogFactory.getLog(this.getClass());
     //a set of restricted resources
     private Set restrictedResources;
     * Initializes the Filter.
     public void init(FilterConfig filterConfig) throws ServletException {
          this.restrictedResources = new HashSet();
          this.restrictedResources.add("/assessment.jsf");
          this.restrictedResources.add("/patients.jsf");
          this.restrictedResources.add("/anesthetic.jsf");
          this.restrictedResources.add("/baseline.jsf");
          this.restrictedResources.add("/drugs.jsf");
          this.restrictedResources.add("/endocrine.jsf");
          this.restrictedResources.add("/haematological.jsf");
          this.restrictedResources.add("/labwork.jsf");
          this.restrictedResources.add("/medication.jsf");
          this.restrictedResources.add("/neurologocal.jsf");
          this.restrictedResources.add("/newpatient.jsf");
          this.restrictedResources.add("/patientdetails.jsf");
          this.restrictedResources.add("/renal.jsf");
          this.restrictedResources.add("/respiratory.jsf");
          this.restrictedResources.add("/riskassessment.jsf");
          this.restrictedResources.add("/summary.jsf");
          this.restrictedResources.add("/minimalquestions.jsf");
          //admin Pages
          this.restrictedResources.add("/admin/admin.jsf");
          this.restrictedResources.add("/admin/drugs.jsf");
          this.restrictedResources.add("/admin/drugs.jsf");
          this.restrictedResources.add("/admin/editdrugs.jsf");
          this.restrictedResources.add("/admin/nurses.jsf");
          this.restrictedResources.add("/admin/newnurse.jsf");
          this.restrictedResources.add("/admin/transaction.jsf");
     * Standard doFilter object.
     public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
               throws IOException, ServletException {
          this.logger.debug("doFilter");
          String contextPath = ((HttpServletRequest)req).getContextPath();
          String requestUri = ((HttpServletRequest)req).getRequestURI();
          this.logger.debug("contextPath = " + contextPath);
          this.logger.debug("requestUri = " + requestUri);
          if (this.contains(requestUri, contextPath) && !(requestUri.contains("admin") ? this.authorizeAdmin((HttpServletRequest)req) : this.authorize((HttpServletRequest)req))) {
               this.logger.debug("authorization failed");
               ((HttpServletRequest)req).getRequestDispatcher(LOGIN_PAGE_URI).forward(req, res);
          else {
               this.logger.debug("authorization succeeded");
               chain.doFilter(req, res);
     public void destroy() {}
     private boolean contains(String value, String contextPath) {
          Iterator ite = this.restrictedResources.iterator();
          while (ite.hasNext()) {
               String restrictedResource = (String)ite.next();
               if ((contextPath + restrictedResource).equalsIgnoreCase(value)) {
                    return true;
          return false;
     private boolean authorize(HttpServletRequest req) {
          UserBean user = (UserBean)req.getSession().getAttribute(USER_BEAN);
          if (user != null ) {
               //user logged in
               return true;
          else {
               return false;
     private boolean authorizeAdmin(HttpServletRequest request) {
          UserBean user = (UserBean)request.getSession().getAttribute(USER_BEAN);
          if (user != null && user.getUserId() != null && user.getUserId().equals("admin") ) {
               //user logged in
               return true;
          else {
               return false;
}

How to configure simple project JSF 2.1 with any Spring Security?

Hi guys,
I need something for beginning, very basic configuration for JSF 2.1 + Spring Security?
Or may by do you know nice and simple security for JSF projects?
Thx

Hi,
I rode Spring manual ;-)
It doesn't help me to integrate JFS+SpringSecurity.
Propably because I pretty new in security apps.
Already, I don't know Maven :-( I've never use it.
+"You'd have to explain what your requirements are. If it is basic user authentication only then you can just use the authentication services built into the JEE specification, which you should research."+
I mean: User can log into service and has rights only for specific files (jsf).
I would be grateful for any help.
Thx
ps.
I can set at list basic Spring+Spring Security.
I've tried "JDBC security realm with glassfish", it works, but setting it is nightmare for me.
Edited by: val75 on Jan 24, 2013 1:46 PM

Project Server 2013 reporting security

HI
I have a question and I have seen a couple similar ones but nothing definitive on the topic of permissions/security for Project server 2013 (in project server security mode) for either Excel(Odata) reports or for SSRS reports.
Even setting security aside the Out of the box configuration is certainly not elegant or even usable.
Situation:
In PWA project managers and team members can only see projects they, own, are team members on, or have been granted permissions explicitly to. (Pretty standard - is using security templates and "my Projects"). We are using secure store
and impersonation for access to reports. We do have report authors groups.
As an example a PM needs to create a weekly status report but should not have to pull all the data back to then filter for their one project.
However, when a PM goes to either SSRS or Excel using oData they can see every project in the company. This is just does not make a lot of sense. Why would I hit the database for 100projects when I only care about one and yet there seems
to be a lack of information on the topic. In contacting Microsoft we were told there was nothing we could do that is how it was designed.
REALLY???? (see above)
What we have come up for our approach is that we're currently using the UserID value to set parameters in our data sources, but are looking for more 'elegant' approaches
to security (if they exist) as there are some liabilities with this approach (EX is a report author forgets to put the parameter in the users will get everything back.
QUESTION:
If there is not another approach then we will stay with it. We can't imagine there isn't a better way.
Additionally, the Project user view only contains the identity of the project owner not the rest of the team members (including sponsors who might need to see the data.) so where are they in the database?
Tasks

Hi Paul,
I have a similar situation only I'm using Project Online. I have setup Groups and Categories where there is a relationship between clients and groups, and projects and categories.
Only issue is that when running a report a user receives an error and then all the data shows for all projects irrespective of the group/category/project relationship and the fact that user only exists in one group (and therefore can't see
or access the other projects in PWA outside of their group.
Hope that makes sense.
Regards,
Conrad

The role of java.security.acl in Java 2 security

I have been trying to assess the role of the java.security.acl package within the Java 2 Security architecture. I have some questions regarding it.
First where in the JVM are the interfaces of java.security.acl used? Are there any examples out there to guide developers in understanding their proper implementation?
What is the relationship between this package and the core security package? There seems to be a Permission interface in the acl sub-package and an abstract Permission class in the core security package. Why is this the case? Why is the core abstract class not used instead of declaring a new Permission interface within the acl subpackage?
Are not PermissionCollections and Permissions analogous to ACLs? If so then wouldn't that fact make the acl subpackage redundant?
JSR 115 tries to bridge the gap between Java 2 Security in the SDK with security in J2EE. Namely enabling the RBAC-like approach to security in J2EE while using the AccessController of the J2SE to do the evalualtion of J2EE (Servlet/EJB) Permissions. Why are the Group and Owner interfaces defined here not leveraged in both JSR 115 and in general for Role Based Access Control?
Could someone give some background on the vision behind creating the acl subpackage and how it relates to the historical progression of security advances in Java security architectures?
Thanks much,
Alex Karasulu

I see from the defined interfaces that its an attempt at a formal approach to RBAC. However RBAC can be implemented without it all together using existing J2SE and JAAS based constructs. This does not answer the redundancy question. Could you elaborate a little bit more?
Thanks,
Alex

Recommended way to secure page

Hi Experts,
Can u tell me what is the recommended way to secure a page??
1. secure page def
or
2. I have to add page in bounded taskflow and secure TF.
Thanks

If you have to restrict access to a whole page which is not part of a BTF, it will be enough to secure the page's PageDef. It is not necessary to wrap the page in a BTF.
If the page is part of a BTF, you cannot secure it alone but you can secure the whole BTF only. Permissions on a BTF are propagated to all the TF activities within the BTF (including the view activities - pages and fragments).
If you need to apply security policies only on particular components within a page, then you can use EL expressions like #{securityContext.userInRole['MyRole']} in order to exclude the necessary components from the view tree (e.g. using components' "rendered" attribute), to hide or disable them (e.g. using their "visible" and "disabled" attributes), to make them read-only (e.g. using their "readonly" attribute), etc. Have a look here for other useful EL expressions:
http://docs.oracle.com/cd/E23943_01/web.1111/b31974/adding_security.htm#BGBIFHDF
For example, you can use this approach to secure menu items and command components (e.g. buttons and links) in other pages that navigate to a secured page or BTF. You should disable or hide these components conditionally if the user has no rights to access the corresponding secured page or BTF. If you do not disable/hide these components, an user could use them, the framework would try to navigate to the page and an exception would be thrown because the user had no rights to access the page.
Dimitar

Securing WebServices call without user login

Hello,
I spawned a thread in the Java Technologies for Web Services forum about different approaches to securing web service interactions.
The security level required is:
- guaranteeing the server's identity (so that the customer does not talk to a phishing server
- guaranteeing the client's identity (so that we don't provide the service for free, and don't leak customer-specific data across customers)
- encrypting the exchanged data
Whichever approach will end up having some local security info stored on the client machine (e.g. client certificate used to guarantee the client machine identity).
Now we have a requirement from some customers that the operator be not required to input any password on the client computer (basically the whole client system is some industrial machine (let's say a steel-knitting machine), and the operator does not knowingly use a computer, but merely a steel-knitting machine with levers and a couple of big plastic square on/off push-buttons).
We also don't have the power or time-to-market to include a hardware authentication mean (e.g. an ID card or dongle).
As far as running our software go, no problem, we will configure the OS to auto-log on startup.
However, we are concerned that the client software, and its client configuration, may be copy-pasted on another machine, and used to sniff our provider's valuable steel-knitting patterns (those data whose transport has to be encrypted).
You may have understood that I am a totally noob as to security aspects. I hope you can help me with the following questions:
- Is there any way to prevent a clone of the client software being copied onto another host?
I guess not; I mean, as far as someone can log onto the machine using the same user as the one the software runs under, he can download the software package, including the configuration and certificates.
- Is there any built-in mechanism that could makes the certificate unreadable or invalid on a cloned machine (e.g., if the certificate includes some terminal-specific info, such as a MAC address)?
- would a check of the client's IP address protect me - I think an attacker can forge its sending IP address, but then he may not receive the reply, is that correct?
Note that we trust our customers to not install more steel-knitters than they bought, so validating the full DNS hostname would protect us. But I'm probably naive to think that we can guarantee against forged domain names.
- It it hopeless? AFAIC, the customer is violating the recommendation to base security on "something he has (conf) plus something he knows (password)". Is it enough of a no-go to pop up the problem to the boss or sales, so that they try to convince the customers?

It's a nogo.Thanks for your valued opinion.
Yes, the more I think about it, the more I'm convinced the requirement is technically unreasonable - although I understand that they want to lower the training and process costs.
(blushing) From a formal point of view (hey, I have a marketing guy to convince first), I haven't found an advisory bulletin from e.g., CERT or OWASP, to support the claim "it's obvious that you can't authenticate a person without a password or a body scan". It must be too obvious...
I'd like to bend their head to authenticating the hardware instead (card/dongle).
What you need here is mutually authenticated SSL with an HSM at the client that requires a password for its use.Yes we are going the mutually authenticated SSL route (subject of the other thread).
As far as using an HSM go, anything more robust that personal cards (which can be a form of HSM) is bound to be too costly for the market.
I'm concerned though about requiring a password: if we force a password scheme onto reluctant customers, I'm convinced we will end up with company-wide passwords shared among all operatives.
Not that different from having a shared (non-password protected) card/dongle that unlocks the machine (e.g. hosts the certificate and compute keys, I don't know too well how an ID card works). The card scheme seems even more secure, as attempts against the card (card lost, stolen, damaged) are more likely to be reported (and trigger revocation of the certificate) than password leaks.
Edited by: jduprez on Sep 14, 2009 3:04 PM

Namespace and security

When I wrote my driver I decided to follow
Walter Oney's advice not to name my device object.
According on Oney, there are security issues that make this approach less secure. I admit that I never understood this point.
So I decided not to name my device but rather to take the "device interface" approach (WdfDeviceCreateDeviceInterface).
Now I need to extend my driver to support many (250) virtual devices and I was advised to use a "namespace" instead of creating 250 device interfaces.
1. What makes named object less secure? An example please.
2. Is it possible to use a namespace with an unnamed device object?
Thank you

Thank you for the excellent replies.
I now understand that not naming my DO was not a wise decision but this will not be reversed. However, I can still name the DO so that its devices will be interfaced either by the new namespace or by
the old interfaces.
250 joysticks?! that's insane ...
Not Exactly. One of my users wants to use it for over-the-net gaming server where many players play simultaneously. Anyhow, the current 16 device limitation was relevant for the old WINMM interface and should be removed.
Whether or not the device object has a name, or not, is not relevant to whether it can have a namespace.
Good news then? Suppose the driver creates this name for my driver interface:
\\?\{d6e55ca0-1a2e-4234-aaf3-3852170b492f}#vjoyrawpdo#1&2d595ca7&147&vjoyinstance00#{781ef630-72b2-11d2-b852-00c04fad5101}\device_001
Can I assume that the string followed by
device_001 is my namespace? If so, what is the use of creating an interface? What happens if I try to create file (CreateFile()) with a arbitrary sub-name such as
\\?\{d6e55ca0-1a2e-4234-aaf3-3852170b492f}#vjoyrawpdo#1&2d595ca7&147&vjoyinstance00#{781ef630-72b2-11d2-b852-00c04fad5101}\device_BlaBla?

PS 9.0 Security - maintaining security in 2 releases.

I am working on an upgrade approach for security 9.0, Our current PS environment is 8.3, with PeopleTools 8.2. We are upgrading to PS 9.0/ PT 8.49. We create Oprid's during a nightly batch cycle. We have taken a copy of our PS 8.3 database, with the PeopleTools tables for the initial upgrade, using Oracle Labs. My question, is there a way to migrate the new production Oprid's that have been created since the initial copy of production. We will not be going live with 9.0 for 16 months, and need to maintain PS Oprid's in the upgrade environment.
Any help is appreciated,
KT Hargett

I do not know why PeopleSoft does not provide a good solution for such situation. i've seen numerous situations where the client need to address this problems through thier own solutions.
In order to preserve security upto date as with production, your golden copy (the target database that was upgraded during initial pass) must be constantly updated with all security tables. There is no one clear cut solutions. What many of them have done is if the length of upgrade project is spanning more than 6 months, they would write a custom process to update the OPRID everytime they do test move to prod and migrate the security tables data to golden copy.
here's what one of the PeopleSoft Customer Connection Solution says:
E-UPG How can you preserve security through upgrade passes? (Doc ID 642944.1)
SOLUTION:
In order to preserve security through your upgrade passes, you will have 3 options.
1) Low Risk - Re-enter your security changes into one of the target databases. Once this is complete, those security tables can be exported out and imported into any other upgraded databases at the same tools release using security migration reDocument:610138.1, included below.
2) Low Risk - Re-do the Initial Upgrade again. This will get the security as it is when you take the copy of production. Many customers chose this option because they are most comfortable with it. Once the initial upgrade is completed, follow the steps outlined in reDocument:610138.1 (Included below) to migrate security to your other upgraded databases.
3) High Risk -
Attention! This workaround has not gone through our formal quality regression test cycle. We strongly recommend that you thoroughly test this workaround in a development environment before applying it to your production environment.
Be sure to document this change as this workaround may be detected during your next upgrade. Because this workaround has not yet gone through our formal quality regression test cycle, this workaround will have risk.
You should only follow this option if you only want the latest operator security in production migrated to your upgraded database. Do the Initial Upgrade again, up through the end of Chapter 2 (Updating PeopleTools). You will need to definitely run the Relnnn.sql scripts, copy the projects and do the alters - but to make sure you get everything correct, it would be best to run all steps in Chapter 2. Once completed your tools release will be at the same level as your fully upgraded database that you want operator security imported into. DO NOT FOLLOW Document:610138.1 as you will LOSE ALL security delivered by the new application release you just upgraded to. To migrate your operator security, select the appropriate Data Mover script for your PeopleTools release to export and import operator security:
For PT 8.4x -
******Export******
USEREXPORT.dms
This script looks as follows:
-- USERS
EXPORT PSOPRDEFN;
EXPORT PSOPRALIAS;
EXPORT PSROLEUSER;
EXPORT PSUSERATTR;
EXPORT PSUSEREMAIL;
EXPORT PSUSERPRSNLOPTN;
EXPORT PS_ROLEXLATOPR;
EXPORT PS_RTE_CNTL_RUSER;
******Import******
USERIMPORT.dms
This script looks as follows:
UPDATE PSLOCK SET VERSION = VERSION + 1 WHERE OBJECTTYPENAME = 'UPM';
REPLACE_DATA *;
UPDATE PSVERSION SET VERSION = VERSION + 1 WHERE OBJECTTYPENAME = 'SYS';
UPDATE PSVERSION SET VERSION = VERSION + 1 WHERE OBJECTTYPENAME = 'UPM';
UPDATE PSOPRDEFN SET VERSION = (SELECT VERSION FROM PSVERSION WHERE OBJECTTYPENAME = 'UPM');
hope this helps
[Learn PeopleSoft HRMS and Upgrade|http://www.learnpeoplesoft.info]

RE: WMI Monitoring - Security

Hi
I am currently using a product to monitor our network which can make use of wmic. Currently connecting to remote machines require a username and password. What would be the best approach to secure wmi communications. I that you have to be part of the local
admin group to see most of the wmi values, but I was wondering if there is any way to create a local user on machines that gets used for monitoring purposes only? Prefereably not part of local admin group.
Thanks
Karl

Hi Karl,
Windows Management Instrumentation (WMI) supports a limited form of security that validates each user before the user is allowed to connect to WMI, on either the local computer or a remote computer. This security is layered on top of the operating
system security. WMI does not override or circumvent security provided by the operating system.
By default, all members of the Administrators group have full control of the WMI services on the managed computer. All
others have read/write/execute permissions on their local computer only.
Reference from:
Managing WMI security
I hope this helps.

JSF AJAX through PhaseListener

Can someone point to a reference article or blog which shows the PhaseListener approach of enhancing a JSF component for AJAX.
A simple example on the way it is implemented will suffice

https://blueprints.dev.java.net/bpcatalog/ee5/ajax/phaselistener.html

Approaches on security in JSF

Similar Messages

Maybe you are looking for