From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Anthony Nadalin
Sent: Thursday, May 24, 2007 8:22
PM
To: Higgins
(Trust Framework) Project developer discussions
Cc: 'Higgins
(Trust Framework) Project developer discussions';
higgins-dev-bounces@xxxxxxxxxxx
Subject: Re: [higgins-dev] H3
deployment configuration issues
Applets are nasty not very consistent across browsers,
these also impose security constraints that involve the user to figure out.
Also you have left out the whole issue around a "secure" card store
as the one that is in RPPS is not dynamic, not secure and not portable. We are
currently looking at the Java KeyStore but to make this useful we would have to
use Java 1.6 and not sure this is a requirement that we could live.
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Paul Trevithick"
<paul@xxxxxxxxxxxxxxxxx>
|
"Paul Trevithick"
<paul@xxxxxxxxxxxxxxxxx>
Sent by:
higgins-dev-bounces@xxxxxxxxxxx
05/22/2007 07:53 PM
|
Please respond to
"Higgins \(Trust
Framework\) Project developer discussions"
<higgins-dev@xxxxxxxxxxx>
|
|
|
To
|
"'Higgins \(Trust Framework\) Project developer
discussions'" <higgins-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
[higgins-dev] H3
deployment configuration issues
|
|
Two
Higgins identity agents (as well as
the Higgins IdP/STS, and a Higgins
RP test site) will be involved in the Catalyst
interop demo (approx 25-27 of
June). One of the agents uses the H3
configuration. And it has problems.
To help discuss the problems, I've created new
& improved documentation here
[1] for both agents. Notice the new deployment
configuration summary table
near the top. Please review the details of
described [3](H3=java) and
[4](H4=native). I have also updated the
Architecture page [2] to split the
RPPS into two separate components (this reflects
reality). I have also
annotated some interconnections with the H1, H2,
etc. deployment
configurations to which they belong.
Andy and others at Novell have been focusing on
the H4 configuration,
whereas Mike and Abhi of IBM, and Valery, Maxim
and SergeyY of Parity
Ukraine, have been focusing on H3.
H3 and H4 differ from each other in two ways.
First, H3 is interpreted
(java) whereas H4 runs native code. Second, H4
embeds the UI (ISS Client UI)
within the native executable, whereas H3 relies on
the UI integrated within
HBX itself.
I have drawn here [2] a line from HBX directly to
the RPPS Core. This is the
intent, and the subject of this email, but NOT how
it works today. Today HBX
makes SOAP calls to the RPPS Webapp (much like
H1).
As I understand it, there are two problems with
HBX's use of SOAP to connect
to RPPS Webapp (vs. some alternative way to
connect to RPPS Core):
1) The size of the code. The presumption is that
if we find some other way
for HBX to talk to RPPS that the size would be
reduced because several
SOAP/XML-related libraries could be eliminated.
2) The installation and run-time complexity: A
separate java process must be
installed and be running at all times.
Soo.....We need to find and evaluate architectural
alternatives to address
these issues. Anyone have experience with
_javascript_-to-java bridges?
Should/could the Higgins
code run as a java applet!? Can we just address the
installation and run-time issues with fancy installers
and live with the OS
background process requirement?
Anyone with ideas about how to solve these issues,
please join the #higgins
IRC channel tomorrow from 10-12am ET (9-11am CT).
-Paul
[1] http://wiki.eclipse.org/index.php/Deployments
[2] http://wiki.eclipse.org/index.php/Architecture
[2]
http://wiki.eclipse.org/index.php/Deployments#H3_Identity_Agent_.28100.25_lo
cal:_HBX_launches_java_application_.28JVM_required.29.29
[3]
http://wiki.eclipse.org/index.php/Deployments#H4_Identity_Agent_.28100.25_lo
cal:_HBX_launches_native_code.29
PS: the H4 configuration Novell uses doesn't have
these issues because it
can simply have HBX (or equiv) launch an
executable. This approach works for
H4 because...
- there is effectively only one method
"getDI" (aka "getToken") that needs
to be supported. Thus all of Higgins can be wrapped up as a single
executable with a single entry point
("main()") and command line arguments.
This works because the UI is contained in the
executable NOT in the browser
extension.
- Higgins
running in native code is fast enough that it can be launched
every time it is needed without appearing sluggish.
PPS: In the short term (for H4) we can use the
perpetual motion add-on to
launch the executable, and in the long term we'll
include this "launch"
functionality within HBX
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
