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
