Any code end up being written for a uPortal B/LTI provider? If so, I'd very much like to kick the tires for a Sakai->SSP [1] SSO/deeplinking use case.
I did check your Jasig/uPortal fork, Steve, but no branch or commit jumped out at me. Same for Jira issues. Thanks. - Dan [1] - https://wiki.jasig.org/display/SSP/Home Steve Swinsburg-3 wrote > Hi Eric, > > Thanks for the detailed reply. Yes, the goal is to render specific > portlets from uPortal in a remote app. A few comments inline: > >> >> 1. uPortal is still using home-brewed security code for authN/Z (in its >> defense it was written before any of the current frameworks were even >> ideas on a whiteboard). So you could write a custom SecurityContext impl >> that authenticates user sessions as you see fit. Part of the current >> design though is it currently requires the user bounce of /uPortal/Login >> to actually get an authenticated session setup. Not sure if that would be >> a problem for you or not. If you want to make all the uPortal developers >> happy you could always take on the task of switching uPortal trunk over >> to spring-security in which case you'd have access to all the authN >> providers they ship with plus what is likely a better API to write custom >> ones against. >> > > I'll have to take a look at this. Bouncing /uPortal/Login in theory sounds > ok because even if someone had that setup with CAS, they should have been > authenticated already so the CAS check should just pass through. > > >> 2. Not sure what you mean by "add them to my app" when talking about the >> uPortal APIs. We're working in trunk to get a better set of REST services >> available for integration but that is about all there is other than just >> sticking your code in the uPortal webapp. Do you have specific features, >> services or tasks you're thinking of when you talk about needing uPortal >> API access? >> > > I meant taking the uPortal impl code and using it in my own app, but after > looking at this some more, adding it to the uPortal webapp would be > easiest. It would sit in it's own URL space as a servlet or similar. > > >> 3. That consistent URL doc is up to date with what is in 3.3. A few >> questions here though, portlets can be viewed in two different states in >> relation to a user. You can view a portlet that exists within the user's >> layout, this portlet has a persistent subscribe ID which portlet >> preferences are keyed off of and can be managed to some extent by the >> user via moving it around in their layout or unsubscribing from it. The >> other option is viewing a portlet by fname. The current logic for this >> first tries to see if the user is subscribed to the portlet and if so >> they interact with the first subscribed instance of that portlet in their >> layout. If they are not subscribed they interact with a transient version >> of the portlet. The portal actually adds the portlet to their layout >> document with a non-persistent subscribe ID, portlet preferences can >> still be saved but without a link back to the portlet a user can't easily >> get back to it on their own. >> > > Some thinking to be done there. Ideally we'd want full access to the > portlet so the one from a user's layout would be best. When the other app > is configured for the LTI launch, it can send arbitrary data along in the > request. So we could send some data which causes the servlet to look up > the subscribe ID and then a URL constructed to reference that particular > instance. > > >> 4. uPortal has support for the exclusive WindowState which facilitates >> this but it does require the portlet be aware of the WindowState and >> decare support for it. Would you need a way to do that rendering on any >> old portlet? > > Ideally any portlet would be able to be rendered in the exclusive window > state. But it's ok for a small set of portlets to support it at this > stage, the other portlets can be progressively be made aware as time > permits or necessity dictates. > >> >> I know you have some experience with OAuth from your other LTI work so >> hopefully you have some insight here. As we work to add more REST API >> support in uPortal we're going to want a way for tools to auth to those >> APIs on behalf of a user. Is OAuth something that could make that work? > > Definitely. We are looking at using OAuth to secure an endpoint of our own > as we need to be able to send client side requests to it from one of our > portlets. So we can't just IP restrict it since the requests will be > coming from the browser. Using OAuth signing means we can protect that URL > space. Even communication between API's could be done this way assuming > the HTTP request overhead wasn't too much. > > Thanks for all the tips, good info and more planning to be done! > > cheers, > Steve > > > >> >> -Eric >> >> On 2/13/11 6:37 PM, Steve Swinsburg wrote: >>> Hi all, >>> >>> I'm looking at adding Basic LTI provider support to uPortal. I already >>> have the portlet going which means uPortal is a Basic LTI consumer, but >>> I'd like to get the reciprocal happening, to make it a provider. This >>> will allow us to use the uPortal portlets in other environments. >>> >>> Basic LTI is essentially a standard way of integrating applications. >>> Think of a POST request that contains a bunch of parameters, with a >>> timestamp and then it is hashed. It's then sent off to some endpoint at >>> the other application. This is a widely used approach amongst >>> integrating LMS's but it's never been standardised until now. >>> >>> With Basic LTI, the parameter names are standardised and the request is >>> signed via OAuth. Signing the request adds a number of security measures >>> like a nonce, timestamp and SHA1 hash of the parameters. There is also a >>> shared key and secret that identifies each consumer (the part making the >>> request) and the secret is also used in signing the request. The >>> receiving end checks the request hasn't been tampered with and if all >>> good, trusts the data in the request and then does it's part. >>> >>> In it's simplest form, the provider simply processes the data, sets up a >>> session for the user if required and constructs a URL to the requested >>> resource. It then performs a redirect to that URL. The consumer makes >>> this request in the context of the browser and an iframe so that >>> whatever session is setup is in the browser already, and whatever is >>> rendered on the other end can be viewed directly in the other app. >>> >>> Tn this case, the provider will be uPortal and will be providing direct >>> access to the portlets. There is a screenshot here of it going the other >>> way around, ie tools from other apps being rendered in uPortal: >>> https://wiki.jasig.org/display/PLT/Sakai+connector+portlet >>> >>> >>> I have a couple of questions before I begin: >>> >>> 1. I'll need to be able to log a user in given only their userId, ie no >>> password. Is there a way to do this? >>> 2. To do 1 I'll no doubt need access to the uPortal API's, I assume it's >>> ok to just add these to my app? >>> 3. How different is the 3.2 API to the 3.3 API? >>> 4. I'll need to construct a direct URL to a given portlet. I read this: >>> https://wiki.jasig.org/display/UPC/Consistent+Portal+URLs - is that the >>> latest doc? And for uP 3.3? >>> 5. Can the portlets be rendered without any of the portal container >>> markup around them? I want to be able to render just the portlet in my >>> external app. >>> >>> thanks, >>> Steve >>> >>> p.s. originally sent to uportal-user by mistake, sending to uportal-dev. >>> -- >>> >>> You are currently subscribed to > [email protected] > as: > [email protected] >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev >> > > > -- > You are currently subscribed to > [email protected] > as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- View this message in context: http://jasig.275507.n4.nabble.com/Basic-LTI-provider-support-for-uPortal-tp3304267p4657838.html Sent from the uPortal Developers mailing list archive at Nabble.com. -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
