Details

    • Type: Technical Task
    • Status: Closed
    • Priority: Minor
    • Resolution: Completed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
    • Sprint:
      AS | Iteration 1, AS | Iteration 2, AS | Iteration 3, AS | Iteration 4, AS | Iteration 5, AS | Iteration 6, AS | Iteration 7, AS | Iteration 9, AS | Iteration 10, AS | Iteration 11, AS | Iteration 12, AS | Iteration 13, AS | Iteration 14

      Description

      The library has been split in smaller ones. All the packages in the classes have changed.

      Library changes - Main differences

      • SamlContext has been changed totally. The class no longer holds all the information it used to. Now that information has been reworked into MessageContext. This class is a container of a type and other subcontexts.
        • For instance the former samlMessageContext.getInboundSAMLMessage() looks like now has to be got using:
          InOutOperationContext inOutOperationContext =
          	samlMessageContext.getSubcontext(InOutOperationContext.class);
          
          MessageContext inboundMessageContext =
          	inOutOperationContext.getInboundMessageContext();
          
          LogoutRequest logoutRequest =
          	(LogoutRequest) inboundMessageContext.getMessage();
          
        • Methods containing information about the local part now have to get that information from SAMLSelfEntityContext and the peer information from SAMLPeerEntityContext, got from MessageContext.
        • Same thing goes when obtaining the information from SAML Binding, Protocol, etc. that information now needs to be requested or stored in the relevant subcontext.
      • MetadataProvider is also gone. Now there exists a different interface called MetadataResolver. The interface seems to be similar and the API is based on Criteria. Looks like it should be possible to delegate most of the work to existing implementations in the library, such as, DOMMetadataResolver
      • The Request/Response Decoders/Encoders have also changed. The main change seems to be that they are not created once and used for many requests or responses. In OpenSAML 3 one instance is set for one context and you need to call init, prepare and encode/decode
      • The classes that were called *Rule now seem to have been rewritten into Handler. These were used for instance in the SecurityPolicy, which is gone.
      • Classes that used to end in Helper now end in Support
      • SecurityPolicyResolver class is gone. Now a similar result is obtained using a generic MessageHandler<?>.
      • IdentifierGenerator is also gone and now it is replaced with an IdentifierGeneratorStrategy. This new interface does not allow to pass a size anymore, so we wrapped it into IdentifierGeneratorStrategyFactory that generates the instance and accepts a size.

      Modularity

      Modularity of the library has also changed. We can't compileInclude the jars anymore, because they register interfaces using java SPI mechanism, which drops files in META-INF/services with the name of the interface they are implementing. Since several modules install implementations for the same interfaces, if we used compileInclude most of these files would be overwritten by the following modules, thus only one would work. This forces us to embed the jars but using Bundle-ClassPath instead of compileInclude.

      Configuration and Bootstrapping

      Modules can register initializers registering this interface

      package org.opensaml.core.config;
      
      public interface Initializer {
          void init() throws InitializationException;
      }
      

      using Java Service API.

      There is also a ConfigurationService as a central point to get or store configuration. Different services, such as Configuration os ConfigurationPropertiesSource can be used to contribute to the ConfigurationService.

      This also has the problem that instances that are lazily initialized might fail to find the proper implementations due to Thread Context Class Loader not being the one containing the implementations, especially in an OSGi environment. In the case of Signer class we have to initialize it using reflection to make sure it is initialized and cached properly since the beginning.

      Method method = Signer.class.getDeclaredMethod("getSignerProvider");
      
      method.setAccessible(true);
      
      method.invoke(null);
      

      same thing happens to

      method = SignatureValidator.class.getDeclaredMethod(
      	"getSignatureValidationProvider");
      
      method.setAccessible(true);
      
      method.invoke(null);
      

      examples of the new configurations used are

      SignatureValidationConfiguration signatureValidationConfiguration =
             ConfigurationService.get(SignatureValidationConfiguration.class);
      

      or SignatureSigningConfiguration that has convenience helper to fetch the configuration from the ConfigurationService: SecurityConfigurationSupport.getGlobalSignatureSigningConfiguration()

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              tibor.lipusz Tibor Lipusz
              Reporter:
              carlos.sierra Carlos Sierra
              Recent user:
              Nóra Szél
              Participants of an Issue:
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Days since last comment:
                1 year, 41 weeks, 6 days ago

                  Packages

                  Version Package