Marina, Thanks for using the jetspeed user list!
Comments below. Randy >-----Original Message----- >From: Marina >To: 'Jetspeed Users List ' >Sent: 12/6/04 5:06 PM >Subject: RE: Jetspeed2 M1 security setup (was: jetspeed-newbie Roles-Groups-Users)> > >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 The /page.security file defines named security constraints that can be referenced here or in individual page, folder meta data, link, or document set documents. The scope of this file is global across the entire site. References take the form of <global-security-constraints-ref/>, (which appear only in /page.security), or <security-constraints-ref/>. >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. Yes, since this fragment is referenced in a <global-security-constraints-ref/>, it applies to all documents in the site. >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. Yes, where used with a <security-constraints-ref/>. >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? Not exactly. The override is in the default-page.psml itself, (user=*, permission=view). >What is the scope of the page.security definitions and >where are they used? See above. >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> This should be commented out in M1. > > <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?) It would be the case if default-page.psml did not override on its own. To be exact, this allows all users to view the folder and any content within it that does not specify its own security constraints. In effect, this is the site default for global pages because it is defined at the root leve. >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. Correct. It also requires that its contents only be visible in the manager role as well. >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> Yes, and it is this that enables any user to view the default page, no matter what the folder that the page belongs to is permitted. >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> Yes, but this is portlet level security within the page. I am not sure if it functional as of M1. If it is, it will apply only to the rendering and actions of the individual portlets. If it is not implemented at this time, it will probably be soon. Let me know if you find out it does not function as per the portlet spec... i'll probably dig in and get it working at some point. >Questions: >-- How do all the security declarations in #1, 2, 3 >and 4 relate to each other? 1-3 are document level security and 4 is restricted to the portlet. 1-3 are related but only as the security constraint of record for a given document. In other words, constraints do not aggregate, (with the execption of the global security constraint references that are applied for all pages/folders metadata/links/document sets). To offset the pain associated with this simplification, constraints that are used often can be defined in /page.security where they can be referenced as necessary. >-- What declarations take precedence? Only the constraint that is "closest" to the resource being accessed is checked. Again, constraints do not aggregate. Essentially, constraints are searched in the document itself, then for each folder metadata back toward the root folder metadata. Once any constraint is found, it is used. Finally, global constraints are checked. If no constraints are located, all access is granted. >-- what declarations are mandatory for others to work? None, really. Do note that <global-security-constraints-ref/> and <security-constraints-ref/> work in conjunction with definitions in /page.security. No constraints specified explicitly or on a parent folder's metadata imply all access is to be granted. >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? This is the new SSO component and really others can answer more accurately than I since I have not had a chance to use it yet. I believe that Basic Authentication is not quite there yet. It is planned, but I am not sure if it made it into M1. But yes, it will be possible to use the IFrame and WebContent portlets with SSO to configure Basic HTTP Authentication. >-- 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? Again, this is SSO. Try looking at the help page for each portlet, (use the help portlet action/button). I imagine that you need to hit the edit page, (use the edit portlet action/button), to change your user/password... otherwise it is going to use your last SSO credentials forever. > Thanks fo rreading this till the end :) >Marina No problem. Good Luck!
