Kyle Mulka's Blog

Cosign is the authentication mechanism that the University of Michigan uses to authenticate users to their web applications. It allows the user of a web application the ability to use their standard University of Michigan uniqname and password with that application safely. The password is always transmitted directly to a secure central server (https://weblogin.umich.edu/) and behind the scenes, that central server tells the web application what the uniqname of the user is via a server side variable. This means that the web application never actually puts its hands on a users password, and even if the service is hacked, it will only affect that one service and not entire users accounts.

For this article, I’m only going to describe the University of Michigan’s implementation of Cosign. It is possible for other institutions to download the entire source code for Cosign and host their own central server which handles all authentication, but I’m not going to cover that since I don’t know much about the Cosign authentication server, just the Cosign which runs on the web server serving the specific web application you want secured via Cosign.

Examples:

• Webmail
• Wolverine Access
• UMOD
• CTools
• liveUgli (my current project)

In order to use Cosign, you have to have it installed on the server your web application is running on. Installing the Cosign client is no easy task. There are many things that make this challenging for someone who doesn’t really know what they are doing. Here’s some things you need to know in order to truly understand what’s going on here.

Cosign requires you have an SSL secured web page (HTTPS) for at least the authentication step of your web application. They reccommend you SSL secure anything that is not public that you have to be logged in to view otherwise user session to your web application could be hijacked.

In order for your web application to communicate with the central authentication server, the webmasters need to sign an SSL certificate for your server. This ensures that the communication between your web application and the central server is always secure.

Installing Cosign from source can always be an interesting challenge, especially if it doesn’t work the first time. I’ll try to go into this in more detail in another article. In the meantime, just check out these notes on my Cosign installation I wrote up a while ago, and the official Cosign web page.

Spread the word…. Mschedule is up for Fall 2006 including the automatic schedule generator! I’ve fixed it once again… But, the domain mIschedule.com is still dead, and probably won’t be coming back to life. Check it out and let me know if you have any problems.

It’s time to announce it to the world! I’ll be working for Amazon this summer in Seattle for about 12 weeks as a Software Development Engineer Intern starting May 8th. I’m really pumped!

I thought this was interesting… I looked in the headers of an email I recieved from facebook. The message said it was sent with ZuckMail. I’m not sure what ZuckMail is, but I’m assuming its named after the head honcho over there at facebook, Mark Zuckerberg. Anyone with more information about what ZuckMail is, please let me know…. I’m interested. Check it out:

Received: from zuckmail ([207.75.132.61])
by wccnet.facebook.com with HTTP (ZuckMail);
Mon, 6 Mar 2006 05:54:32 -0800

X-Mailer: ZuckMail [version 1.00]

So, apparently I have my phone number listed on the internet. Yes, in fact I do. You can see it by clicking “contact me” on the right side of my page. Apparently some girls in Oregon like to search for “random weird” images on Google Image Search. My contact information is in an image and you can find it by searching for that phrase. I’m on like the 20th or so page. They decided to call me up and tell me that my number was on the internet. They were curious why my number was on the internet. I was like… so people know what my number is if they want to call me. I haven’t had any problems yet with my number being up there. I guess that’s just me and my trusting nature. They were suprised that they were the first people to randomly call me like that. If you want their phone number, let me know… I have it on caller ID.

So, my last entry was about Blue Puddle, my research project for the semester. This entry is about my other project for the semester called liveUgli.

What is liveUgli? Here’s the description straight from the about page:

“liveUgli is for finding students who are doing the same thing as you, right now. Find a classmate to ask a question, or a nearby friend to study with.”

Basically, a user sits down somewhere in a study space on campus either with a laptop or at a one of the many computers, logs into liveUgli selects a building and floor, and clicks on their location on a floorplan. We’re working hard to get location detection in place so that this process is semi-automated for the user. They can also tell us which class they are studying for and what specifically they are working on.

While on the site, they can browse through the floor plans and see who is studying what where. If they tell us what classes they are taking and who their friends are, we can limit the view to just their friends and classmates.

So, once they have found someone they may be interested in studying with, asking a question of, or taking a study break with, they can either visit them in person, or instant message them via AIM, MSN, etc. or our own messaging system which has yet to be implemented.

We’ve been in close contact with Jeff Powers who is building Mates pretty much by himself now. We plan on using the services Mates provides to power liveUgli.

The other project Jeff is working closely with is Ping. Basically, it is a smartphone client for Mates.

We like to think of liveUgli as a web-client for Mates, but its much more than that.

I know I haven’t written a real entry in a while. Lately, I’ve been working on my two major semester long (at least) projects for school. They are both websites and they both use the Google Maps API. How cool! I’ll explain the first one in this entry, and the second I’ll leave for another entry.

The first is called Blue Puddle. It is a student-initiated research project funded by GROCS. Basically, we want to be sort of like Wayfaring, sort of like Yellow Arrow, sort of like Map Hub but better in our own little unique kind of way. I think there are a few other sites I could list… If you really want to see them click here.

There are four students working on the project: two grad students in the School of Art and Design: Zack Denfeld and Brent Fogt, one grad student in the School of Information: Nika Smith, and me, Kyle Mulka, an undergrad in the College of Engineering.

Here’s the blurb from the proposal that (I think) Zack wrote that makes our project sound pretty interesting and research-like:

“The Blue Puddle software takes advantage of the Internet’s distributed authorship capabilities to create maps that draw on users’ collective memory and subjective experience of a city. These maps foster the emergence of stories about the city that are richer than any single author could create. The virtual digital environment created by Blue Puddle will serve as a catalyst for engaging the real built environment.”

One cool toy we are using is a digital GPS camera. It records latitude and longitude in the actual jpeg when you take the picture. We (well.. the Digital Media Commons really) bought the Ricoh Caplio Pro G3 digital camera from GeoSpatial Experts along with their GPS-Photo Link software. When we tried out the camera with the software for the first time, we realized we didn’t actually need the software at all. In fact, we are re-implementing a portion of their software using Google Maps which makes it 10 times cooler. I’m not a fan of their automatic web page creator. Although it gets the job done of putting a set of GPS photos on maps, its pretty ugly.

So… if you have feedback on the site, let me know via comments on this blog post, or via email. Keep in mind though, its not even close to being done.