Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "RP Website Solution"

(Architecture)
(See Also)
 
(7 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Architecture ==
+
== End-User Perspective ==
[[Higgins-deploy-rp-v47.JPG]]
+
A running instance of this deployment is available here: https://higgins.eclipse.org/RelyingPartyDemoApp
  
==Details==
+
Or if you wish to go directly to a protected page, here: https://higgins.eclipse.org/RelyingPartyDemoApp/protected
 +
 
 +
== Developer Perspective ==
 +
 
 +
=== Architecture ===
 +
[[Image:Higgins-deploy-rp-v47.JPG]]
 +
 
 +
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===
 
{| class="wikitable" style="text-align:left; border="1" cellpadding="5" cellspacing="0"
 
{| class="wikitable" style="text-align:left; border="1" cellpadding="5" cellspacing="0"
 
|-style="background:#d6dee9; color:black"
 
|-style="background:#d6dee9; color:black"
Line 21: Line 32:
  
 
== See Also ==
 
== See Also ==
* [[Deployments]]
+
* [[RelyingPartyDemoApp Deployment]]
  
 
== Links ==
 
== Links ==
 
* [http://eclipse.org/higgins Higgins Home]
 
* [http://eclipse.org/higgins Higgins Home]

Latest revision as of 13:47, 28 March 2009

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

Higgins-deploy-rp-v47.JPG

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

See Also

Links

Back to the top