RE: [higgins-dev] Feedback on Higgins STS Architecture diagram

["Brian Carroll" <BCarroll@xxxxxxxxxx>]

Dear Tony, Mike, et al,

First of all, thanks for the great news about the upcoming release of
the STS and for the diagram!  Here is some feedback on the architecture
diagram:

1. Overall the architecture seems well-thought-out - sufficiently
abstract with some (but perhaps not all) extension points defined. Looks
like a good foundation.

2. The core architecture seems to be based the RST and RSTR of WS-Trust.
That is a good initial choice, but we probably want some abstraction in
that area (e.g., the Framework Independent STS Implementation) so the
STS could handle the SAML Protocol as an alternative to WS-Trust in the
future.  Perhaps an abstract notion of "Request for Token" and
"Response", where either WS-Trust or the SAML Protocol could be plugged
in.

3. I like the fact that there is both a callable API or a remote
interface (i.e, the WS-Trust web service interface). Though I need to
think about the SecurityPolicy Enforcement handling being "above" that
API?  What is the use case for the API?

4. I did not see an extension point for persisting the tokens that have
been issued or revoked (e.g. Revocation List).  We touched on that as an
ALF requirement at the last F2F.

5. Other than the "Security Policy Enforcement handling" box, I did not
see any boxes or extension points for WS-Policy or obtaining policy via
WS-MetadataExchange. [Perhaps that was too much detail for a single top
level diagram.]

6. I did not see extension points for other forms of credentials, such
as X.509 or Kerberos.  Have you assumed that would be buried in one of
the Frameworks (e.g. Axis 2) at the top of the diagram.  Won't we need a
box (or extensibility point) to handle the mapping of the claim
information in other forms of credentials to a SAML token?  [Again, we
may simply need a second level diagram that expands the single
"Framework Independent STS Implementation" box.]

7. If, based on the policy for a given context/AppliesTo, the STS needs
to provide a different form of credential in the RSTR (e.g. the service
being accessed only recognizes X.509 certificates and does not handle
SAML tokens), where on the diagram is the extension point for that?
[I've assumed that in the initial implementation, only SAML tokens will
be returned in the RSTR.]

8. It was not clear where the STS interfaced to the IdAS to obtain claim
information.  I would think it would be through one of the Plugins at
the bottom of the diagram, but was surprised that and IdAS plugin was
not explicitly shown.

9. It would be good to ensure that in the pluggable architecture, the
choice of provider can be made dynamically, rather than the more static
pluggability of the java.Security property file.

10. Should there be SPIs or extension points defined for future
administrative, management, and health monitoring of the STS.  I would
not expect these capabilities to be implemented initially, but would
expect extension points to be defined in the architecture.

11. Should there be some logging interface, so someone could audit which
tokens have been issued?  [Again, I'm more interested in defining the
extensibility point now than actually having an implementation.  There
are some security issues about what would be placed in the log and how
is the log secured, so the implementation may be a bigger task than we
want to tackle initially, but we should define the extension points.]

12. Where on the diagram would support for the Passive Requestor Profile
be implemented?

Some general questions on the functional capabilities:

1. Which WS-Trust Request types will be supported: Issue, Renew,
Validate, Cancel/Signoff?

2. What will be the capabilities "out of the box" - that is, if someone
installs the STS, what can it do?  What other components must be
provided to make the STS functional in a typical customer environment?
For example,
    a) What default extensibility plugins will be available? For example
- an LDAP context provider plugin would be useful.
    b) Exactly what functionality has been "factored out" of the STS
itself, and into the plugins at the bottom of the diagram?
    c) What will an "out of the box" WS-Security Policy Enforcement
Handler do?
    d) Will the Passive Requestor Profile be implemented initially, or
only the Active Requestor Profile?

3. What functions will be exposed through the ...Extension.invoke(STS
Request) interface?  I'm assuming the interface will be broader than
simply a "invoke()" operation.  

4. What is used by the STS to determine which Higgins Context Provider
will be used?  (I'm assuming the Higgins IdAS will be one of the plugins
at the lowest layer of the diagram.)  Will the AppliesTo element from
the RST be used as a selector, or will the Context be chosen based on a
Policy component?  How will that policy be conveyed from a "WS-Security
Policy Enforcement Handler" to the "Framework Independent STS
Implementation" box?

5. There will probably need to be some administration control point to
specify what the pluggable Framework at the top of the diagram are to
do.  For example, will the frameworks will perform the digital signing
of the SAML Token in the RST or will that be done in the "Framework
Independent STS Implementation" box.)  If message level security is
needed for the RSTR, how will the framework be told to provide that?
[An acceptable answer would be that you simply have to code that and
that such things are not specified through a policy or properties file
initially.  If so where would that code go?]

Thanks again. Hope this feedback is useful.  Reply on the mailing list
if my questions are not clear, or if my questions reveal I've not
understood some aspect.

Regards,
Brian

Brian Carroll
Architect, Eclipse ALF project
www.eclipse.org/alf
Serena Fellow
Serena Software
(ofc)  (503) 617-2436
(cell)  (503) 318-2017
bcarroll@xxxxxxxxxx 



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.