280 likes | 449 Views
The Sakai JSR-168 Portlet (Version 2). Charles Severance csev@umich.edu December 17, 2005. New in Portlet Version 0.2. Announcements (sakai.announcements) Assignments (sakai.assignment) Chat Room (sakai.chat) Discussion (sakai.discussion) Gradebook (sakai.gradebook.tool)
E N D
The Sakai JSR-168 Portlet(Version 2) Charles Severance csev@umich.edu December 17, 2005
New in Portlet Version 0.2 Announcements (sakai.announcements) Assignments (sakai.assignment) Chat Room (sakai.chat) Discussion (sakai.discussion) Gradebook (sakai.gradebook.tool) Email Archive (sakai.mailbox) Membership (sakai.membership) Message Forums (sakai.messageforums) Preferences Tool (sakai.preferences) Presentation (sakai.presentation) Profile (sakai.profile) Resources (sakai.resources) Wiki (sakai.rwiki) Tests & Quizzes (sakai.samigo) Roster (sakai.site.roster) Schedule (sakai.schedule) Site Info (sakai.siteinfo) Syllabus (sakai.syllabus) • Tree View • Gallery View • Proxy portlets • Source in SVN • Configurable via properties file
Use Case (getting closer) • Goal: a bunch of Sakai Portlets that can be scattered through out a portal at the portal administrator’s discretion - it is *almost* as if Sakai was in the portal. • Not quite there • One weakness is the provisioning step - for the proxy portlets they need provisioning. • Another weakness is the need to synchronize AUTHZ between the portal and Sakai - give than none of the AUTHZ in portals is standard at all, this is a challenge • Even though portals may not have the infrastructure to support a “group-scoped” calendar, we may have to build one anyways.
Sakai JSR-168 Portlet • Web Services are used to login to Sakai establish a session and retrieve a list of Sakai Sites, Pages, and Tools • The portlet is 100% stock JSR-168 • Works in Pluto, uPortal, and GridSphere
Three Variations • Display the Sakai gallery - all of Sakai except for the login and branding. • Retrieve the hierarchy of sites, pages and tools display in a tree view with the portlet and show selected tools/pages in an iframe within the portlet • Proxy tool placement for a particular Sakai tool such as sakai.preferences
SakaiSite.getToolsDom <sites> <portal>http://localhost:8080/portal</portal> <server>http://localhost:8080</server> <gallery>http://localhost:8080/gallery</gallery> <site> <title>My Workspace</title> <id>~csev</id> <url>http://localhost:8080/portal/worksite/~csev</url> <pages> <page> <id>af54f077-42d8-4922-80e3-59c158af2a9a</id> <title>Home</title> <url>http://localhost:8080/portal/page/af54f077-42d8-4922-80e3-59c158af2a9a</url> <tools> <tool> <id>b7b19ad1-9053-4826-00f0-3a964cd20f77</id> <title>Message of the Day</title> <toolid>sakai.motd</toolid> <url>http://localhost:8080/portal/tool/b7b19ad1-9053-4826-00f0-3a964cd20f77</url> </tool> <tool> <id>85971b6b-e74e-40eb-80cb-93058368813c</id> <title>My Workspace Information</title> <toolid>sakai.iframe.myworkspace</toolid> <url>http://localhost:8080/portal/tool/85971b6b-e74e-40eb-80cb-93058368813c</url> </tool> </tools> </page> </pages> </site> </sites> New WS method is upwards compatible with getSitesDom
How Gallery Works /portal/gallery Charon Portal Sakai uPortal, Pluto, or GridSphere Sakai Portlet Web Svcs Login
How Tree View Works Charon Portal /portal/page/FF96 Sakai uPortal, Pluto, or GridSphere ToolList Sakai Portlet Web Svcs Login
How Proxy Portlet Works /portal/page/FF96 Charon Portal 2 Sakai uPortal, Pluto, or GridSphere SiteList Sakai Portlet Web Svcs 1 Login
Auto Login • Automatic login (unchanged from previous version) • The portlet can be configured system-wide to have a designated Sakai host that people are to be automatically logged into. • A shared secret between the portlet and the Sakai system allows bypass of any Sakai log in. • There must be a Sakai account for each portal account. But if the account exists and the shared secrets match, integration is seamless • If the portal is fully provisioned and knows first name, last name, and e-Mail, SakaiPortalLogin can also auto-create users.
How Normal Login Works /portal/gallery Charon Portal 2 Sakai uPortal, Pluto, or GridSphere Sakai Portlet Web Svcs SakaiLogin 1 (id,pw)
How Auto Login Works /portal/gallery Charon Portal 2 Sakai uPortal, Pluto, or GridSphere Sakai Portlet Web Svcs Request.getRemoteUser = “csev” PortalLogin Configuration: sakai.secret=abcdef sakai.host=http://… 1 (id,secret) Configuration: sakai.secret=abcdeff
How Normal Login Works Charon Portal Sakai uPortal, Pluto, or GridSphere Sakai Portlet Web Svcs Request.getRemoteUser = “csev” PortalLogin Configuration: sakai.secret=abcdef sakai.host=http://… (id,secret)
Configuration • Configured via both a properties file and portlet <init-parms> • Default properties is in /WEB-INF/classes/org/sakaiproject/portlets/sakaiportlet.properties • This file can also be placed in the -Dsakai.home directory as well - this will override the default file • Portlet.xml <init-parms> override these properties but out of the box, the portlet.xml does not set these properties
sakaiportlet.properties file # # This sets parameters for sakai portlets # # These values are overridden by any init-parms in the portlet.xml or # init-parms forced by the portal sakai.host = http://localhost:8080 # It is convenient for testing to have the secret set out of the box # But in production, if you do not want autologin, do not set this parameter # and autologin will be turned off sakai.secret = plug-xyzzy # This is used to deal with non-portable aspects across portals - such as how # to determine the current logged in user. Leaving it null assumes that it # is an Apache Pluto based portal. # portal.type=gridsphere # portal.type=uportal
Notes • If you don’t use auto-portal login, it is very painful to use the proxy portlets (sakai.calendar, etc) because they need to establish login separately :( • There is a bug in 2.1 logging out from the gallery. Actually it might be best to hide the logout button as it is not really logical in a mode where some “higher level” portal is doing navigation. • Char does not work - need to figure out why. Probably an interaction with presence
TODO List • Create “group placed” versions of the proxy portlet - need to interoperate with the AUTHZ in the Portal and in Sakai • Need to look very closely at how AUTHZ is done in the portal and what APIs to call for each portal - this will likely be a “case statement” • Need to look closely at preferences in the portal, normally there are portlet-wide init parms and user-scoped preferences. Is there an intermediate level where an admin can set certain prefs that end-users cannot override? This will likely also be non portable. • Make tool placements in tree view look like page placements - should this be in Charon or in the Portlet? Effectively this is snatching some Charon code to do the titles, etc. Would be better to do this in Charon.
Outline of (TBD) AUTHZ • It is pretty clear that it is dangerous to depend on the AuthZ of the Portal because all portals will be different. • Build a service inside of Sakai which maps Portlet Placements to Sakai Sites • Allow users with site.upd to effectively grant a “role” to a portlet placement. • Another variant is to have folks “auto-join” sites and get a role in the site that way.
Portlet Calendar portlet placed by admin with ID FF12 Current AUTHZ Calendar portlet executed by hao - no placement in pref - find placements What calendars can hao see? Site User Role AB23 csev maintain AB23 hao access BC55 hao maintain BC55 marlon access AB23 BC55 hao picks BC55 and it becomes his personal pref. Calendar portlet executed by csev - no placement in pref - find placements What calendars can csev see? AB23 Since there is only one csev sees it and it becomes his pref
Portlet Calendar portlet placed by admin with ID FF12 TBD AUTHZ - Maintain case Calendar portlet executed by hao - no placement in pref - find placements What calendars can hao see? AB23 BC55 (site.upd) hao picks BC55 and then is asked, would you like this to be a group placement? If so, what role do people get when they see this placement? Hao says “yes - access”. Site User Role AB23 csev maintain AB23 hao access BC55 hao maintain BC55 marlon access Does hao have site.upd in this site? Yes Grant Portlet FF12 access role in AB23. Portlet Site Role FF12 AB23 access hao sees the AB23 calendar and it becomes his preference. Sweet
Portlet Portlet Site Role FF12 AB23 access Calendar portlet placed by admin with ID FF12 TBD AUTHZ - Access Case Calendar portlet executed by csev - no placement in pref - find placements What is the placement portlet FF12? Sakai notices the placement rule made by hao, and also that csev does not have access, and adds csev as access below. csev is sent to the AB23 calendar and it becomes his preference. AB23 Site User Role AB23 csev maintain AB23 hao access BC55 hao maintain BC55 marlon access BC55 csev access
Portlet Calendar portlet placed by admin with ID FF12 TBD AUTHZ - Maintain case(more detail) Calendar portlet executed by hao - no placement in pref - find placements What is the placement portlet FF12? Portlet Site Role Null Since there are no placements, lets check to see if hao can see any calendars. Site User Role AB23 csev maintain AB23 hao access BC55 hao maintain BC55 marlon access What calendars can hao see? AB23 BC55 (site.upd) Since hao has site.upd, he picks BC55 and indicates that this placement gets the access role. Grant Portlet FF12 access role in AB23. Portlet Site Role FF12 AB23 access hao sees the AB23 calendar and it becomes his preference. Sweet
Summary • This is a nice step forward for the Sakai JSR-168 portlet • There is another step needed to truly meet the ideal use case • This step needs some analysis by within-portal security folks (I.e. I need help from the uPortal and GridSphere experts to determine next steps) • This will meet a set of needs much better than version 0.1 of the portlet. • The gallery and tree should work well • Proxy portlets can be used in certain cases where AUTHZ is well considered. • This version is “safe” from a security perspective - it only allows users to do what Sakai permits them to do.