You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
a portlet-filter to prime the uPortal security integration for any authenticated user / establish uPortal spring security integration for REST webapp calls. Creates an object that can be used within Spring Security and places it in HTTP Session. The object contains:
The principal information (username from userInfo.get(username)
All groups the user is in go into the Granted Authorities (for Spring Security hasRole("rolename"). Rather than adding only those roles from the elements in the portlet.xml, I suggest retrieving all the groups the user is in from uPortal. I personally don't see that as a security issue. Check into how SSP is doing that (Paul S, Dan M, or Drew W) and determine if that mechanism is sufficient or if
we want to pass all the user's groups via a request attribute (functional with uPortal only which is fine)
create a generic callback mechanism to reach into uPortal's public APIs (which would be great) this is my preference if it is not too much work. I prefer something like a special attribute in the PortletRequest that is a map of services exposed by the portal. This way it is extensible (add in groups, later add in permissions, later add in ...).
or other approach that is flexible and secure.
This additional work should be done with a UP Jira
an Apereo-custom field that provides access to the user attributes. I prefer to get all the user's attributes from the portal, which would require an extension of the portal's API (like groups above). The initial implementation can just use those defined in the section of the portlet.xml which means they are available from request.getAttribute(PortletRequest.USER_INFO) -- see https://wiki.jasig.org/display/UPM42/Consuming+User+Attributes
Implement:
The text was updated successfully, but these errors were encountered: