4 Replies Latest reply: Feb 26, 2008 11:22 AM by richwolf
Chris Gray - NAU Level 1 Level 1 (5 points)
We've been going around around about how to deal with private access to iTunesU courses and the passing of credentials.

And please forgive me if I've missed something obvious here, I'd love for that to be the case!

In a perfect world, I would like to pass all of user's enrollment credentials, LDAP group credentials, etc. into iTunes so that once a user is authenticated into it, all of the authorization tokens already exists and the user can freely browse around to whatever content he/she has access to.

However, due to the fact that credentials are passed in the query string, this doesn't seem feasbile because we have some administrative users who would have more credentials than would fit in the url.

Thus the only solution I can come up with that makes sense and is consistent is to require each access to a specific course in iTunesU be linked from an external source like a webpage or our LMS and then only pass the credential to iTunes that corresponds with that particular class. This means that once a user is in iTunes via a course link, they would need to go back out to find another link to get into a different course instead of just browsing to it from within iTunes.

Now again, if I've missed something obvious or if anyone would like to share what their institution is doing in this regard I'd be very grateful for the input.

Thanks!

Message was edited by: Chris Gray - NAU

Message was edited by: Chris Gray - NAU

Windows XP
  • 1. Re: How do you deal with multiple credentials?
    Ben Rogers Level 1 Level 1 (40 points)
    Huh, sounds similar to something we ran into in the past (max characters in a URL in IE) but I thought that was more or less resolved and we are passing like a million credentials for everyone at this point. To help folks who know more than both of us, could you define the limitations to URL size that you see, that are causing you this problem?

    Oh, and at least in our case we are using Shibboleth and only passing the relevant attributes (isMemberOf and eduCourseMemeber), although we're thinking about mashing both of those into eduCourseEntitlement on send-time. Also, our administrators are over the whole site so I actually have less relevant credentials than some folks enrolled in classes, who can build up 40 or so eduCourseMember credentials over their tenure.

    Ben Rogers
  • 2. Re: How do you deal with multiple credentials?
    richwolf Level 3 Level 3 (725 points)
    Chris,

    Well, here are some data points that I hope you will find useful. Overall, I think Ben has this about 100% correct.

    A token string can, according to Apple, contain up to one-hundred credentials. That's a lot of credentials. Further, each credential can be as long as 1,024 characters. I wouldn't say it's impossible that someone could hit those numbers ... but they are pretty high.

    In practical terms, you're limited to the length of the URL that any browser can deal with. Sadly, it looks like the one with the greatest issue is Explorer. In Explorer, no URL can have more than 2,083 characters in it (unless you are POSTing). So I would look at 2,083 as sort of an absolute maximum ... actually, a bit less than that once you take into account signature, identity, timestamp, and base URL. Ballpark, I'd go with 2000 characters.

    But 2000 characters can pack a lot of credentials ... certainly as many as forty or fifty (maybe more than that ... depending on how you set them up). So, "typically" you can expect to go anywhere from about 50 credentials, to the theoretical maximum of 100 ... depending on their respective size ... and keep both Apple and Microsoft happy. The other browsers are way more robust and can easily handle 100 credentials.

    My advice would be that you can always grow into an increasingly complex credentialling scheme ... you can experiment on a small scale and ramp up. Also recall that permissions flow down in an iTunes U site. That is, you can assign a generic credential to everyone at the top level of your site, and refine access as users drill down into a site. You could give administrators a credential which marks them as such, then let them have broad powers over large sections of your site. Because of their admin credential, they wouldn't need to carry a whole set of others (because the access you have at any "place" in an iTunes U site is the most access that any of the credentials you hold allows at that "place").
  • 3. Re: How do you deal with multiple credentials?
    Chris Gray - NAU Level 1 Level 1 (5 points)
    Thanks to both of you for your replies. They were helpful in thinking through this problem. The issue we have is that we have over 100 individuals who have over 100 course enrollments across all of our active semesters in our LMS. So that means we have a decent sized population for which we couldn't sent the entire list of their enrollments as credentials.

    However, while talking with another member of my team, he came up with what I hope will be a perfect and elegant solution. We're going to try, upon login, to pull a list of available credentials from iTunesU and compare that list with the list of enrollments, group memberships, etc. from our local identity store and only pass those that actually exist in iTunesU. This should solve all of the issue since it will likely not happen that a person has over 50-100 actual iTunesU credentials that apply to them. (if we end up with that sort of adoption we have a much bigger set of issues to deal with anyways.

    Thanks again for the input and any feedback on our approach here is welcome as well.
  • 4. Re: How do you deal with multiple credentials?
    richwolf Level 3 Level 3 (725 points)
    Ahhhh ... I think I understand your problem better now.

    Your LMS contains all the credentials any user might ever hold ... and not just those that user holds during any particular semester. So when you pass credentials, many might not yet be "in play" so-to-speak. In that case, I really love your solution ... I think it is correct. What's even more nifty, is that you need not necessarily get a list of creds with every access to iTunes U ... since creds are orthogonal to users, your system can periodically poll iTunes U to get an updated list of creds and cache it locally.