[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [higgins-dev] H3 deployment configuration issues

So I don't think that we have an architecture that works for all deployments nor do we have one that everyone is following. Architecturally H2, H3 and H4 should be almost the same, using same service interfaces. H3 will wind up aligning more with H4 but will start a Java process. It seems that H1 is the odd man out but the architecture is centered around that (for now) and is not working for local deployments.

Also I did not see the code for H2 and H4 in Eclipse, so are these valid ?


Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Inactive hide details for "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>


          "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
          Sent by: higgins-dev-bounces@xxxxxxxxxxx

          05/27/2007 01:00 PM

          Please respond to
          "Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx>

To

"'Higgins \(Trust Framework\) Project developer discussions'" <higgins-dev@xxxxxxxxxxx>

cc

"'Valery Kokhan'" <valery@xxxxxxxxxxxxx>

Subject

RE: [higgins-dev] H3 deployment configuration issues

As I see it, weâve got an architecture, but serious problems with our i-card provider plug-in implementations. In the âlocalâ configurations (e.g. H3, etc.) we need implementations that persist card objects securely either locally or in the cloud as you pointed out. And we donât have those now.

It may be possible that these same new âsecureâ plug-ins could also be used in the H1-type configuration. Iâll see if Valery and SergeyL think this could work, or whether weâre better off with two separate sets of plug-ins.

[AndyH and others at Novell have done related work but until their stuff is brought into alignment with the common architecture, itâs hard to have a discussion about âi-card providersâ implementations at all at this point.]


From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Anthony Nadalin
Sent:
Saturday, May 26, 2007 1:41 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

So what you are saying is that everyone should just do what they want and not have an architecture

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Inactive hide details for "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>

                  "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
                  Sent by: higgins-dev-bounces@xxxxxxxxxxx

                  05/25/2007 06:34 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

RE: [higgins-dev] H3 deployment configuration issues



Regarding applets:
Agreed. We backed off of this idea on the #higgins channel on Thursday. H3 has been redefined and the wiki updated.

Regarding card stores:
Today the Parity Ukraine team and I have decided that the very recent addition of a separate i-card store provider plug-point to RPPS (in addition to the existing i-card provider plug point) isnât worth the added complexity. We currently think that the existing, single i-card provider plug-point is sufficient because a large part of the responsibilities of an i-card object (as implemented by an i-card provider plugin) have to do with data management, security and persistence. Now back to your pointâDifferent i-card provider plug-ins can clearly implement these things differently. The ones that Parity Ukraine has been working on are not secure and, when used in the H3 configuration, are not portable. I canât comment on whether they are âdynamicâ cuz Iâm not sure what you mean. It might just be the broken state of the code at the moment. I do agree that we need alternative/new implementations of the i-card providers for the H3 configuration to provide proper security and portability (e.g. ability for the cards to be persisted in the cloud).

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

Inactive hide details for "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>"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_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/higgins-dev_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev

GIF image

GIF image

GIF image

GIF image

GIF image

GIF image