Hi, I've successfully built and installed J2 M1 and was looking into the demo applications to figure out how to setup access control for portlets/pages. After checking out some example portlets , like RoleSecurityTest and Login, and their source code, I think I have some idea of how to approach the task but I would like to clarify some topics. First, I'll list my assumptions and then ask questions:
1. tomcat-5.0.30-j2-M1\webapps\jetspeed\WEB-INF\pages\page.security file specifies 'Edit'/'View' permissions for the default Portal's page, defined in default-page.psml Thus, this part : <security-constraints-def name="admin"> <security-constraint> <roles>admin</roles> <permissions>view, edit</permissions> </security-constraint> </security-constraints-def> means that only a user with the role 'admin' can edit the layout of the page. And this fragment: <security-constraints-def name="manager"> <security-constraint> <roles>manager</roles> <permissions>view</permissions> </security-constraint> </security-constraints-def> means that a user with the role 'manager' can view the page. However, anybody can view this default page in reality - even before a user logs in. You don't need any special privileges to access http://localhost:8080/jetspeed to see the page. My assumption is that it is because security constraints are "overwritten" in the pages/folder.metadata file (see below). Is that true? What is the scope of the page.security definitions and where are they used? 2. each folder under /pages directory (including /pages itself) has a folder.metadata file where more <security-constraints> are defined for that folder. For example, here is pages/folder.metadata: ..... <security-constraints> <security-constraint> <roles>user</roles> <permissions>view</permissions> </security-constraint> <security-constraints-ref>manager</security-constraints-ref> </security-constraints> <security-constraints> <security-constraint> <users>*</users> <permissions>view</permissions> </security-constraint> </security-constraints> </folder> And this is why all users can see the default page. (Is that true?) On the other hand, here is pages\Administrative\folder.metadata : <folder> <title>Jetspeed Administrative Portlets</title> <!-- allow only manager role --> <security-constraints> <security-constraints-ref>manager</security-constraints-ref> </security-constraints> </folder> This folder corresponds to the "Jetspeed Administrative Portlets" menu item in the 'Folder and Pages' menu on the left side of the Portal window. However, it is displayed only when a user with the 'manager' role logged in. 3. There also are security-constraints in the .psml files themselves. For example, pages/default-page.psml has: <security-constraints> <security-constraint> <users>*</users> <permissions>view</permissions> </security-constraint> </security-constraints> 4. Also, there are <security-ref> defined in the portlet.xml files of individual portlets. For example: <portlet id="RoleSecurityTest"> ..... <security-role-ref> <role-name>Administrator</role-name> <role-link>admin</role-link> </security-role-ref> <security-role-ref> <role-name>Manager</role-name> <role-link>manager</role-link> </security-role-ref> <security-role-ref> <role-name>User</role-name> <role-link>user</role-link> </security-role-ref> </portlet> and corresponding <security-roles> are defined in the web.xml file of the portlet application: <web-app> .... <security-role> <description>The admin role</description> <role-name>admin</role-name> </security-role> <security-role> <description>The manager role</description> <role-name>manager</role-name> </security-role> <security-role> <description>The user role</description> <role-name>user</role-name> </security-role> </web-app> Questions: -- How do all the security declarations in #1, 2, 3 and 4 relate to each other? -- What declarations take precedence? -- what declarations are mandatory for others to work? 5. By looking at the jakarta-jetspeed-2-M1\applications\demo\src\webapp\WEB-INF\web.xml file I noticed that there were two example SSO servlets registered - SSODemoServlet and SSOBasicDemoServlet, and they were mapped to /sso-demo and /sso-basic URLs respectively. Here is how /sso-basic is protected: <security-constraint> <web-resource-collection> <web-resource-name>HTTPBasicDemo</web-resource-name> <url-pattern>/sso-basic/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>tomcat</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>Jetspeed</realm-name> </login-config> When I access this servlet as http://localhost:8080/demo/sso-basic I am getting a login screen that prompts me to enter username and password, as expected. The /sso-demo is not protected in the web.xml and when accessing it as http://localhost:8080/demo/sso-demo you just get an authentication error. Source code of the SSODemoServlet gives some explanation: /** * SSODemoServlet - looks for username, password in the URL for single * signon to this servlet from a SSO portlet. * Username request parameter: ssouser * Password request parameter: ssopw A few questions here: -- how can you use these servlets from your portlets if you want to utilize the Basic authentication mechanism? Should I just call RequestDispatcher.include("/demo/sso-basic")? If not - how else could I use these servlets in portlets? Or, maybe, not use servlets at all but get the Basic authentication working for portlets somehow? -- when supplying incorrect username/password for the SSOBasicDemo servlet, you get an error page in the browser and if you try to reload it it would not work and would not let you to retry login, until you start a new browser session. I checked my browser settings (both Mozilla and IE) and made sure they do not cache pages between requests - still the same problem. I'm sure it's something very simple - but what? Thanks fo rreading this till the end :) Marina __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]