[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [higgins-dev] Feedback on Higgins STS Architecture diagram
|
Sorry its taken so long to respond - sending this from vacation -
hopefully will get a chance to connect and replicate soon...
higgins-dev-bounces@xxxxxxxxxxx wrote on 07/27/2006 09:39:17 PM:
> 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.
Thanks.
> 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.
I think the Relying Party toolkit will be where protocol specific things
like that (SAML, WS-Federation Passive, etc.) would go, using the STS on
the back end via the abstraction provided by WS-Trust to Issue, Validate,
etc.
> 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?
I think this interface needs some work - the intention is to avoid
serializing complete SOAP/XML when the caller is co-located. Obviously
this is a co-located only deployment scenario, and there will need to be
some form of security policy enforcement - but not WS-Security based.
> 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.
Yes. I have been working on this - discussing with some plugin
implementers whether this should be the responsibility of the STS "core"
or the Token Plugins. I think the consensus is that the "core" should do
this and I will be revising the architecture soon.
> 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.]
Thanks for pointing this out - I've been focused, perhaps too much, on the
co-located deployment scenario. I do need to show the architecture
components needed in each scenario. Perhaps a single core architecture
overview and several deployment scenario specific architecture overviews.
>
> 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.]
The Token Plugins along the bottom are configurable. Ones could be added
for X.509 and/or Kerberos. Hopefully I will be able to walk thru a example
at the next F2F?
> 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.]
An X.509 Token Plugin could do this.
> 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.
Yes. I need to add some form of claim value access provider. My current
understanding is that in the co-located scenario it would obtain claims
from the ISS, not directly from the IdAS.
> 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.
I am not 100% sure I understand what you are asking for, we can talk about
this when I get back.
> 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.
Probably, but I'd hate to guess at what these would look like without more
concrete ideas about how they would be used and at least one potential
implementation to test with.
> 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.]
I have used the Apache Commons Logging fraemwork throughout, we can talk
about a common set of log messages at some point soon.
> 12. Where on the diagram would support for the Passive Requestor Profile
> be implemented?
This would be part of the Relying Party deployment scenario, and is
missing from this picture.
> Some general questions on the functional capabilities:
>
> 1. Which WS-Trust Request types will be supported: Issue, Renew,
> Validate, Cancel/Signoff?
Token Plugins would be configured to to handle specific combinations of:
WS-Addressing Action
WS-Trust TokenType
WS-Trust RequestType
WS-Trust Issuer
... and potentially other fields at some point ...
to the Java class that implements the plugin.
The example below shows the configuration file for the STS configured to
know about Kim's blog (Target/AppliesTo), mapping it to the required
TokenType and Issuer. Then the Action, TokenType, RequestType, and Issuer
are mapped to a class that implements the plugin.
<STSExtensionMap>
<Target
AppliesTo="https://www.identityblog.com/";
TokenType="urn:oasis:names:tc:SAML:1.0:assertion"
Issuer=
"http://schemas.microsoft.com/ws/2005/05/identity/issuer/self"/>
<Extension
TokenType="urn:oasis:names:tc:SAML:1.0:assertion"
Action=
"http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue";
RequestType=
"http://schemas.xmlsoap.org/ws/2004/04/security/trust/Issue";
Issuer=
"http://schemas.microsoft.com/ws/2005/05/identity/issuer/self";
Class=
"org.eclipse.higgins.sts.server.extension.SAML_1_0.ref_impl.SelfSignedIssuerFactory"
/>
</STSExtensionMap>
> 2. What will be the capabilities "out of the box" - that is, if someone
> installs the STS, what can it do?
Currently there is only the self signed issuer, and it does not yet
support Cancel and Validate (I am in the progress of implementing support
for those RequestTypes now).
> What other components must be
> provided to make the STS functional in a typical customer environment?
We can talk about what set of Token Types need to be supported at the F2F.
Since this is an extension point I have not worried too much about
directly supporting many in the core in the first release.
> For example,
> a) What default extensibility plugins will be available? For example
> - an LDAP context provider plugin would be useful.
I think an Identity Provider or Relying Party deployment scenario could
require access to an LDAP Repository and that would be done via the "claim
value access provider" described in #8 above.
> b) Exactly what functionality has been "factored out" of the STS
> itself, and into the plugins at the bottom of the diagram?
Most ;-).
...
> c) What will an "out of the box" WS-Security Policy Enforcement
> Handler do?
The intention is to enforce the configured WS-SecurityPolicy. I need to
think thru how robust this needs to be in the first cut - I am leaning
towards adding a SecurityPolicy attribute to the Extension element
described in #1 above.
> d) Will the Passive Requestor Profile be implemented initially, or
> only the Active Requestor Profile?
This will be implemented in the Relying Party toolkit.
> 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.
I think this will be easy to explain with a code walkthru.
> 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.)
In the co-located scenario, the ISS will invoke the STS. It seems like
having the ISS pass the claim values to the STS in the request makes sense
in that scenario. The STS would not need to call back into the ISS/IdAS to
access claim values, and would not need to know which context was used by
the ISS.
> Will the AppliesTo element from
> the RST be used as a selector, or will the Context be chosen based on a
> Policy component?
The context will be chosen based on the iCard selected by the
user/matcher.
> How will that policy be conveyed from a "WS-Security
> Policy Enforcement Handler" to the "Framework Independent STS
> Implementation" box?
N/A.
> 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.
The WS-SecurityPolicy will likely describe the processing required by the
WS-Security handler.
Eventually there will need to by a management interface for that - but it
will likely be a configuration file at first.
> 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.)
Niehter, it will be done in the SAML Token Plugin (for the Issue
RequestType).
> If message level security is
> needed for the RSTR, how will the framework be told to provide that?
The WS-SecurityPolicy.
> [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?]
The WS-Scurity handler.
> 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.
The feedback is useful. I hope my answers help and that I can get a change
to post more documentation, JavaDoc, Code soon.
> 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.
>
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
