Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
RP Website Solution
Contents
End-User Perspective
A running instance of this deployment is available here: https://higgins.eclipse.org/RelyingPartyDemoApp
Or if you wish to go directly to a protected page, here: https://higgins.eclipse.org/RelyingPartyDemoApp/protected
Developer Perspective
Architecture
This Relying Party implements an application dependent on authentication context, and tries to model how an application might look both with and without personalization based on identity. The RP is implemented as a Servlet 2.2 filter so that it can easily be incorporated into a Web application environment. What that means is that tailoring can happen in the web.xml file in the Web Application aRchive (WAR) file, and the servlets/EJBs/JSPs need not be terribly concerned about the details.
The way the web.xml file is initially wired up, any references to files in the "protected" directory tree will trigger presentation of a login page via the login.jsp (the name of the jsp is configurable through web.xml). This will inform the user that the web application needs some identity information and allow them to select which flavor of identity-selection-triggering should take place (Object tag or xhtml). Assuming the user is employing an identity-aware browser, the Identity Selector is then triggered, which allows the user to select a card, which then goes off to the Identity Provider, whose results are then forwarded to the Login servlet backend, which decrypts the token, verifies its signature and extracts a set of identity assertions (e.g., First Name, Last Name, Birthdate, IQ) for the Relying Party to use in tailoring its data to the now-understood identity.
Details
| OS | Runtime | Binding | Open | URL | Owner |
|---|---|---|---|---|---|
| Fedora 5 | JVM 5.0, Tomcat 5.x | CardSpace (X)HTML interaction type | TBD | site | Bruce |