Digitaliser.dk

Hej Jesper

Thank you for reporting the problem and solution. We are still working on planning a new release of OIOSAML.NET and this will be added to that.

Brgds Brian Nielsen

Hej Jan

Prøv lige og se om der er noget i denne tråd du kan bruge:

http://digitaliser.dk/forum/2323777

Med venlig hilsen
Brian Nielsen, DIGST 

Hej Brian,

Tak for hurtigt svar.

5.1 2d er ok
Måske er det min webconfig.... den har flg

    
IDPEndPoints metadata="C:\spdata\
  add id="http://infk2udv03:80/idp/"
    CertificateValidation
       add type="dk.nita.saml20.Specification.DefaultCertificateSpecification, dk.nita.saml20"
    CertificateValidation
  add
 IDPEndPoints
        
      
   

Ser det ikke OK ud?

/jan

Hej Jan

Ift. denne første test er formålet 'bare' at få det det at virke. Jeg vil foreslå at du anvender følgende til certifikat validering som angivet i den anden tråd:

dk.nita.saml20.Specification.SelfIssuedCertificateSpecification

Jeg antager at de test certifikater der følger med eller genereres er selfsigned?

Mvh. Brian

Hej Brian,

Yes, Så er den hjemme Takker.

Jeg måtte desuden udkommentere

if (int.Parse(Saml20Identity.Current["dk:gov:saml:attribute:AssuranceLevel"][0].AttributeValue[0]) < 3)

i MyPage.aspx filen fordi der ikke er noget indhold for dk:gov:saml:attribute:AssuranceLevel ...... kan du give en kort forklaring eller link til hvad det er?

Så bliver det alligevel jul
/Jan

Hej Jan

Congrats. 

Helt grundlæggende signalerer Level of Assurance (LoA) hvilket sikkerhedsniveau der har været for autenticitetssikringsprocessen.

Se yderligere i vores vejledning Vejledning vedrørende niveauer af autenticitetssikring. Se f.eks. "2.4 Niveauer af autenticitetssikring og risikoprofiler. Beskrivelse og eksempler". 

Ifølge release noten til OIOSAML.NET 1.7.5 skulle der være "Test option in SP page for AssuranceLevel", men jeg har ikke selv prøvet det.

Glædelig jul.

Hi Simon

First thing I would do is track the HTTP traffic to see if get send back to your SP. Pick your favortie tool for this like fiddler, TamperData and WireShark.

Judging from a quick google search in our svn it looks like the IActions should be logged out in dk.nita.saml20.protocol.Saml20LogoutHandler:

private void DoLogout(HttpContext context, bool IdPInitiated)

Best regards
Brian Nielsen 

Hi Steinar

Thanks for sharing your finding. I've not heard of problems related to 4.5, but maybe a minor change to the libraries provoked this. Can you send me the metadata file that gave you that error (send to brian@digst.dk) then I'll try and reproduce it here. 

Best regards
Brian Nielsen 

Unfortunately we also have the same problem. The problem is on the SP side in the Login handler. We discovered it because some developers installed VS2012 even though the SP code is still in VS2010. VS2012 installs .NET 4.5

Today I have confirmed that this is in fact the problem. I installed Win7 + VS2010 in a Virtual Machine. And confirmed that the SP Site worked.

Then I Installed VS2012 and made no other change. Then I opened the site in VS2010 as normal. But now the parsing of the Metadata fails as described by Steinar Herland.

Hi Jesper

Thank you for following up and help pinning the problem. Have any of you tried fiddeling with the metadata file to find what part/markup trigger the parsing problem? That will be needed in going further and either finding another way to implement it or reporting it as a bug to Microsoft.

Brgds Brian

I have pinpointed the problem to one XML Attribute.

If I remove the attribute protocolSupportEnumeration from the element

IDPSSODescriptor

The Parsing of the Xml succeeds. But what is the purpose of this attribute and why does it fail in .NET 4.5 ?

(OBS: The exception occurs when newing up the Saml20MetadataDocument in the ParseFile method. In the constructor of the Saml20MetaDocument the metadata is deserialized and this fails)

I have a distilled the problem into a ConsoleApp

Turns out I can solve the problem without changing the metadata by changing

protocolSupportEnumeration in the RoleDescriptor class to be a string instead of a string[]

Is this an OK solution ? Why was it an array in the first place ?

Hei,

The following program works with .net 4.0, but fails after installing .net 4.5:

Testet with metadata from (norwegian) feide:

Production: https://idp.feide.no/simplesaml/saml2/idp/metadata.php

Test: https://idp-test.feide.no/simplesaml/saml2/idp/metadata.php

Hopefully somebody can look into this realy soon...

Best regards,

Steinar Herland

--

class Program
    {
        static void Main(string[] args)
        {
            var metadataDirectory = new DirectoryInfo(Path.Combine(Directory.GetCurrentDirectory(), "Metadata"));
            foreach (var file in metadataDirectory.GetFileSystemInfos("*.xml"))
            {
                try
                {
                    Console.WriteLine("Loading metadata from " + file.FullName);
                    var xml = LoadFromFile(file.FullName);
                    var entity = Serialization.DeserializeFromXmlString(xml);
                }
                catch(Exception ex)
                {
                    Console.WriteLine("Error loading metadata from file " + file.Name + ": \n" + ex.Message);
                }
            }

            Console.WriteLine("Press any key to continue...");
            Console.ReadKey();
        }

        private static string LoadFromFile(string metadataFilename)
        {
            var entityDescriptor = new XmlDocument { PreserveWhitespace = true };
            entityDescriptor.Load(metadataFilename);
            var xml = entityDescriptor.OuterXml;
            return xml;
        }
    }

Vedhæftede filer

• Program.cs

Great work Jesper. 

Before making any conclusions, just a little ground work on what the standard says.
First the XML format, where the xml attribute protocolSupportEnumeration is defined in xsd for SAML Metadata as:

<attribute name="protocolSupportEnumeration" type="md:anyURIListType" use="required"/>
<simpleType name="anyURIListType">
<list itemType="anyURI"/>
</simpleType>

and this make it reasonable that it's mapped to an array (XML Schema list Element).

The specification OASIS Security Assertion Markup Language (SAML) V2.0 (PDF) describes it with

protocolSupportEnumeration [Required]
A whitespace-delimited set of URIs that identify the set of protocol specifications supported 
by the role element. For SAML V2. entities, this set MUST include the SAML protocol namespace URI, 
urn:oasis:names:tc:SAML:2.0:protocol. Note that future SAML specifications might share the 
same namespace URI, but SHOULD provide alternate "protocol support" identifiers to ensure 
discrimination when necessary.

So to keep the SAML compliance this will be kept as an collection/array.

My current (best) guess is that the way the (de)serializing has been implemented in oiosaml.net somehow has depended on undocumented or overseen documentation aspects. The relevant classes seem to be:

dk.nita.saml20.Saml20MetadataDocument (ViewVC)

dk.nita.saml20.Schema.Metadata.RoleDescriptor (ViewVC)

and I almost foregot

dk.nita.saml20.Utils.Serialization

public static T DeserializeFromXmlString<T>(string xml)

So if the protocolSupport attribute is still going to be a string[] what then would be the workaround ?

As I (and Steinar too) have shown the deserialization fails in .NET 4.5.

But this can be solved by making the protocolSupport of the RoleDescriptor a string instead of a string[].

Even though the spec. reads otherwise I don't see a problem with this in the current code, since there is never more than one element in the array.

So if the protocolSupport attribute is still going to be a string[] what then would be the workaround ?

As I (and Steinar too) have shown the deserialization fails in .NET 4.5.

But this can be solved by making the protocolSupport of the RoleDescriptor a string instead of a string[].

Even though the spec. reads otherwise I don't see a problem with this in the current code, since there is never more than one element in the array.

BTW: In the spec. you quote in comment 7 it says: "A whitespace-delimited set of URIs" this must mean that there is only one attribute but it can contain several URIS this must mean that this attribute should be split in code using the .NET split method instead of during the deserialization.

I will change our code to use a single string until the OIOSAML.NET is updated to reflect my suggestion (or something similar)

Hi Jesper

I'm no .NET whizz, but I would be surprised if .NET 4.5 cant handler XSD ListType. Maybe the class can be augmented more precisely with Attributes?

Having a closer look it seem to me that the wrong value has been used in the attribute

[XmlAttributeAttribute(DataType="anyURI")]
public string[] protocolSupportEnumeration {

it should be list instead of anyURI, BUT XmlAttributeAttribute.DataType Property does not support it :-) So I guess it would be better to have it but a string and then tokenize it when setting the property. That should work right?

The other way round it's also set as a string array

private void ConvertToMetadata(SAML20FederationConfig config, KeyInfo keyinfo)

I am aware that it probably wont make any difference for OIOSAML usage (though not sure), but the toolkit is also used for other (non OIO)SAML scenarios. 

Hi

Jesper, sry I didn't see your last comment before I posted - yes, we agree (since .NET does support it directly).

Fine :). Have you alerted the folks who update OIOSAML.NET about the problem ?

After installing .Net 4.5 in my system, I am also getting the same error message. Is there a solution or workaround for this issue?

Will there be a new version of the software released?

I really appreciate any help in solving this issue.

Thanks,

Suhas

Hi Jesper and Suhas

We are right now making the list of changes/features that'll go into the next release and this issue is on that list. It will take some time before it'll get into a release, so until then you can pull the source from trunk, make the small change and build your own dll (it's the same we are going todo since it's OSS :-)

Best regards
Brian Nielsen 

Hi Thomas

Thank you for the tip. I see not that it's line 133 in Saml20SignonHandler.cs (ViewVC on our SVN).

Hi Balaji 

I'd guess the Service Provider is not configured for SSO reponse with POST binding. Can you please write the URL where you get the error? Have you turned up for logging and what's in the logs?

Best regards
Brian Nielsen 

Hi,

  Thanks for your reply. I got the assertionservice and I wrongly uploaded the metadata. Now i got the output. I have tested all the functionality from visual studio. Now I am trying with IIS and I got the certificate validation issue. "The X.509 certificate chain building failed. The certificate that was used has a trust chain that cannot be verified. Replace the certificate or change the certificateValidationMode. The revocation function was unable to check revocation for the certificate.". I have tried both default and selfservice certificate settings in config, but still i am getting the same error. Please help me to fix this issue.