Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Nice explanation of iTunes U authentication

I was having problems understanding how the above works, and Richard Wolf, who is assisting us in getting our site up and running, e-mailed me the following explanation, he agreed to let me post it.
I hope it helps others that may be stuck...it's in two parts, here it is:

iTunes U credentials are in the form of MACE URNs united to a "role". More on roles in a bit ...

Formally speaking, a URN is a URI and similar to a URL (a URL is also a URI). The main difference between a URN and a URL is that a URN "names" something within the web whereas a "URL" locates it. But the distinction that used to exist between a URL and URN is now a lot fuzzier than it once was. After all, URLs often do "name" things today ... and URNs often do contain the notion of "location" within them. But, for simplicity, think of a URN as a fancy way to "name something" on the web without necessarily locating it anywhere in particular. For example, you could have "color:red" ... or "suit:spades" ... these "names" wouldn't exist at any website ... they'd just be a common way of naming "things" within the web.

Technically speaking, a URN does not have to start with "urn" just as a URL does not have to start "url" ... a URN could start out like this: "isbn:" or "color:" just as a URL can start out "http:" or "ftp:". However, it's common to start out URNs with "urn:" ... that way, there's no confusion. After the "urn:" part, URNs follow the same rules for construction as any URI would. There's a whole RFC devoted to URI and URN formation.

MACE is the "middleware for education" initiative and is part of the Internet2 project. MACE has formally claimed a subset of the URN namespace. Again, there is an formal RFC that explains/refines MACE's URN subset rules. Apple, in turn, has claimed a subset of the MACE URN namespace ... specifically for use with iTunes U.

So you basically have this:
All possible URNs ---contains---> all MACE URNs ---contains---> all iTunes U URNs

This "containment" is shown in the form of every iTunes U credential. They all start out this way:
urn:mace:itunesu.com

In order to distinguish things you name at Connecticut College from staff I name at UIC, Apple adds a site subset to each URN:

urn:mace:itunesu.com:sites:conncoll.edu
urn:mace:itunesu.com:sites:uic.edu

Basically speaking, the powers that be outside Apple own this part of all iTunes U URNs:
urn:mace:itunesu.com

And Apple owns this part:
sites:conncoll.edu
sites:uic.edu

We own everything that goes after.

This "ownership" prevents any of us from naming things in such a way that we create any namespace conflicts. Anything after our site name is stuff that we ourselves own ... we can name things however we want (so long as we don't introduce any local namespace conflicts). What you do with your part of the URN namespace is only limited by your imagination.

So you could create URNs that look like this:
urn:mace:itunesu.com:sites:conncoll.edu:liberal-arts
urn:mace:itunesu.com:sites:conncoll.edu:liberal-arts:english
urn:mace:itunesu.com:sites:conncoll.edu:liberal-arts:english:101
urn:mace:itunesu.com:sites:conncoll.edu:liberal-arts:english:101:section-2
urn:mace:itunesu.com:sites:conncoll.edu:liberal-arts:english:101:section-2:seat- 24

"In theory" you do not need the "urn:mace:itunesu.com:sites:conncoll.edu" part of the URN ... but if you omit it, you run the risk of a namespace conflict with some other site.

Also, as I'm sure you've noticed by now, the parts of the URN are separated by colons.

Okay, now onto roles ...

In iTunes U, a "credential" is the sum of a "role" and a "context". The context is given by the URN and the "role" is what a user of iTunes U assumes within that context. So you could have:

Instructor@urn:mace:itunesu.com:sites:conncoll.edu
-- an "instructor" within "Connecticut College"
Student@urn:mace:itunesu.com:sites:conncoll.edu:liberal-arts:english:101
-- a "student" within "English 101 at Connecticut College"
Dean@urn:mace:itunesu.com:sites:conncoll.edu:liberal-arts
-- the "dean" of "Liberal Arts at Connecticut College"
Again, "roles' are anything you can imagine. Apple does predefine some roles though ... there is the "Administrator" role, the "All" role, the "Authenticated" role, and the "Unauthenticated" role. Other than those roles, you can have whatever other roles you like. Roles are what makes sense to you and how you want Connecticut College's iTunes U access to work.

A "permission" in iTunes U is the sume of a credential plus an access level. Access levels are only defined by Apple. The three most commonly used access levels are "NO ACCESS", "DOWNLOAD", and "EDIT". When you give an access level to a credential, you are saying that someone holding that credential has that access (usually within the context described within the credential). For example, if you give Instructor@urn:mace:itunesu.com:sites:conncoll.edu "EDIT" access within a specific course, then any person holding the that credential will be able to edit the course.

So, in summary, we've got this:
An iTunes U Permission = Credential + Access Level
Credential = Role + Context
A "Context" in iTunes U is given in the form of a MACE URN
A "MACE URN" is basically a name you want to assign some entity (a class, college, etc) at your school.

Intel XServe, Mac OS X (10.6.2)

Posted on Feb 20, 2010 1:45 PM

Reply
6 replies

Feb 20, 2010 1:56 PM in response to Frank Fulchiero

Ok, here is Richard's Part Two:

When Apple deals with users of iTunes U, they have, effectively, no idea who the user making a particular request actually "is". All user interactions with iTunes U, even administrator accesses, are just "sessions" to Apple ... they're just connections ... there is no specific "user" involved. So how does Apple know how to restrict access for the user who initiates one session from another user who initiates a different session?

Well, every iTunes U session carries with it a set of credentials. A credential is like a high-school hall pass ... it doesn't say who the person bearing it actually "is" ... but it does say what "role" the person bearing it "has" ("AV tech" or "student aide" or "sick person") and in which context the bearer's hall pass is valid ("the projection room in the auditorium" or "the librarian's office" or "the nurse's office"). A high school student might carry multiple passes at the very same time ... each would be valid within a specific context ... which pass is used depends upon the context. So the "library" pass would be used when the student wants to assume the role of "student aide" in "the librarian's office".

This system of high school hall passes ... well ... it utterly depends upon a trusted party to issue the passes in the first place. For example, only a trusted teacher who actually "knows" a student can issue him/her the "student aide" pass the visit the "library". The librarian might not know a particular student ... but if the librarian knows that a trusted teacher issued that student a properly-formatted hall pass, he/she should let the student in with all the privileges that such a pass allows the student to have within the context of the library.

This is EXACTLY how iTunes U crednetialling works. You are like a trusted teacher that "knows" your students and that issues them iTunes U credentials. In fact, that is precisely the role o the iTunes U portal website ... it takes users and maps them onto a set of credentials. Apple then uses those credentials to create an iTunes U session for the user, granting him/her any rights associated with those credentials. The credentials that you use are entirely up to you ... Apple simply honors them. Since every site is different -- has different rules/roles -- the credentialling one site might setup could be utterly different from another's. That is why the Admin Guide is so very vague about the iTunes U portal website ... it describes "in general" what you need to do, but leaves the specifics up to you. Apple simply cannot know the way in which you might like to map users to credentials.

When chatted about the kind of setup you wanted for Connecticut College, you said that you wanted to create four basic roles ... "student", "faculty", "manager", and "sysop". Those seemed like reasonable roles, so they were mapped this way:

student --maps-to--> Student@urn:mace:itunesu.com:sites:conncoll.edu
faculty --maps-to--> Faculty@urn:mace:itunesu.com:sites:conncoll.edu
manager --maps-to--> Manager@urn:mace:itunesu.com:sites:conncoll.edu
sysop --maps-to--> Administrator@urn:mace:itunesu.com:sites:conncoll.edu

The only guy I really altered here is "sysop" ... since Apple predefines the "Administrator" role, I assumed you probably wanted to map "sysop" to it.

But notice that the context in each of the defined credentials for Connecticut College (the MACE URN part) is no more specific than your entire site ... there is no way I could make it more specific because I do know what students will be in what classes. Based upon the groups you defined on your portal, I can determine if a user is "in" a group ... and once I know that a user is a part of a group, I can assign a corresponding credential. Since an iTunes U session is not limited to just one credential, the portal checks whether a user is in any of the four groups and adds a corresponding credential if he/she is. For example, I put myself in each of your four groups ... so if I login to your iTunes U site, I'll have a session with all four credentials ... I'll assume all four roles. Take me out of a group, and the next time I login to your portal, I won't have the corresponding credential.

Mar 15, 2010 11:13 AM in response to Frank Fulchiero

Nice explanation.
One thing that's not clear to me is whether a credential must exist all the way through the hierarchy.

Assume I have courses A and B, at site urn:mace:itunesu.com:sites:mycollege.edu
For each course, I have roles Student and Instructor.
My goal is to only provide download access to the course material for A to students in that class, and edit access only to instructors of that class.

Instructor@urn:mace:itunesu.com:sites:mycollege.edu:A
Instructor@urn:mace:itunesu.com:sites:mycollege.edu:B
Student@urn:mace:itunesu.com:sites:mycollege.edu:A
Student@urn:mace:itunesu.com:sites:mycollege.edu:B

My inclination is to define these roles and their accesses by going to the Edit Access page associated with courses A and B, but to not add them to the Edit Access page associated with the site mycollege.edu, and at the site mycollege.edu, add a "no access" except to site administrators.

This would be the best practice, would it not?

John

Mar 15, 2010 4:08 PM in response to johnrodkey

johnrodkey wrote:
Nice explanation.


Thanks! I never wrote the follow up though…the part about the ${IDENTIFIER} substitution and the way permissions "flow down" in iTunes. You found the issue just the same though. 🙂

One thing that's not clear to me is whether a credential must exist all the way through the hierarchy.


In iTunes U, permissions "flow down" from a containing page to subordinate entities/pages. There is a little caveat to this rule that applies to iTunes U sections…but you need not worry about that when you're just starting. If you define a permission on your site root page, it will flow down to all subordinate pages.

Assume I have courses A and B, at site urn:mace:itunesu.com:sites:mycollege.edu
For each course, I have roles Student and Instructor.
My goal is to only provide download access to the course material for A to students in that class, and edit access only to instructors of that class.

Instructor@urn:mace:itunesu.com:sites:mycollege.edu:A
Instructor@urn:mace:itunesu.com:sites:mycollege.edu:B
Student@urn:mace:itunesu.com:sites:mycollege.edu:A
Student@urn:mace:itunesu.com:sites:mycollege.edu:B


This is what the ${IDENTIFIER} substitution is for.

D'you ever notice the way when you create a new course, there are three fields to fill out? There's the long name of the course, the short name (which appears in iTunes bread crumb area) and the "identifier"? Every wonder what "identifier" does? 🙂

Let's say you have two courses:

Long Name: A 101 -- Introduction to A
Short Name: Intro to A
Identifier: A101

Long Name: B 101 -- Introduction to B
Short Name: Intro to B
Identifier B101

You could then define just two credentials on your site root page:

Instructor@urn:mace:itunesu.com:sites:mycollege.edu:${IDENTIFIER}
Student@urn:mace:itunesu.com:sites:mycollege.edu:${IDENTIFIER}

and iTunes U would automagically define these creds for Intro to A:

Instructor@urn:mace:itunesu.com:sites:mycollege.edu:A101
Student@urn:mace:itunesu.com:sites:mycollege.edu:A101

and these for Intro to B

Instructor@urn:mace:itunesu.com:sites:mycollege.edu:B101
Student@urn:mace:itunesu.com:sites:mycollege.edu:B101

Since permissions flow down in iTunes U, any course that has an identifier anywhere in your site will get similar creds automatically.

Of course, you still have to map people to creds in your transfer script, but that is the subject of your other post to the forums… 🙂 🙂

Nice explanation of iTunes U authentication

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.