weblogin

Here's a brief overview of the components. The CGI & Daemon make up
"Weblogin" in the diagram. Filter is the cosign part that runs on
"Service" in the diagram.

cgi: The central cgi is responsible for logging users into and out of
the central cosign server. It is also responsible for registering each
service a user logs into - this action ties the user's central login
cookie to their session on individual application servers such as our
web mail client, web directory client, or CourseTools environment. The
prototype CGI was built to use Kerberos V/GSSAPI to authenticate the

http://middleware.internet2.edu/webiso/

WebISO is a generic technology. The Internet2 efforts at catagorizing the services and features is an excellent introduction to this topic. The site includes additional detailed documents for the serious web integrator.

http://middleware.internet2.edu/webiso/docs/draft-internet2-webiso-target-side-models-01.html

This is an excellent document that covers a lot of scenarios for integrating webiso with local applications. It's a must read for webiso integrators.

[phpwiki]
We've put together a [weblogin demo page|http://lab.ac.uab.edu/node/view/145] that highlights the single-sign on feature of weblogin and the ability to secure different documents using weblogin.

It would probably be good to have an advanced set of examples that highlights some of the sublte configuration choices available to the web site administrator

[phpwiki]
The decision to enable or disable these features is left at the sole
discretion of the person running the web site. It does not require
coordination with the weblogin service. In fact, the only steps required
of a website administrator to use the weblogin service are to request a
DNS entry and a certificate for the server they are deploying, a standard
procedure with our existing IT services.

[phpwiki]
Some web sites simply need secured access to documents. Advanced web
applications may define their own additional authorization rules. How it
is used, is completely up to the application designer.

[phpwiki]
This is important for two reasons. Firstly, it provides a common trust
point for the end user. This becomes increasingly important in an
environment where the user is required to authenticate to a large number
of applications. During authentication, the user is being asked to give
away the password for their BlazerID. This is a critical piece of data
that controls access their personal information. It is important that
users can have a trusted login interface that ensures protection of their
password.

Secondly, it provides a tamper proof way for web site designers to

[phpwiki]
It is up to the application designer to decide if they want to allow
users transparent access to a web site based on their web login session.
Web application designers can just as easily decide to force the user to
provide their password for every page request they make. This ensures that
users can't just walk away from their browsers leaving critical
applications unprotected and provides the "signature" feature

It's important to understand these four points about the features of the weblogin service we have built using Pubcookie. These points help clarify that the weblogin service is an appropriate solution
for secure web authentication for a wide range of web applications and help web designers think about how to integrate it with their applications. It should actually be the rarest cases where the weblogin service is not applicable.

These points help highlight the applicability of the weblogin service for a wide variety of applications. It's also worth noting that the weblogin service can easily leverage personal certificates for user identification, should we have those available some day.