1. Try to log into some service and type some search terms that yield no institutions found.
2. Press enter
3. You're redirected to the first IdP in the original list

Allow immediate key rollover by simply exposing new endpoints where the new key is selected.

Steps to reproduce:

1. Cleanup cookies related to IdP selection by WAYF (engine.surfconext.org "selectedIdP")
2. Login using IdP 1
3. login to another SP. The WAYF will now correctly present IdP 1 as the pre selection
4. Use IdP 2 to login
5. Login to yet another SP
6. WAYF will now present IdP1, not IdP 2
   It should however preselect IdP 2

My cookies:
Host: engine.surfconext.nl
Name: selectedIdp
Path: /authentication/idp/
Content: https%3A%2F%2Fidp.surfnet.nl
Content raw: https%3A%2F%2Fidp.surfnet.nl
Expires: di 04 nov 2014 17:08:38 CET
Expires raw: 1415117318
Send for: Any type of connection
Send for raw: false
Created: wo 02 apr 2014 10:35:16 CEST
Created raw: 1396427715874516
Last accessed: di 05 aug 2014 09:36:51 CEST
Last accessed raw: 1407224210813410
HTTP only: No
HTTP only raw: false
This domain only: No
This domain only raw: false
Policy: no information available
Policy raw: 0
Status: no information available

Status raw: 0

Host: engine.surfconext.nl
Name: selectedIdp
Path: /authentication/idp/process-wayf/
Content: https%3A%2F%2Fidp.surfnet.nl
Content raw: https%3A%2F%2Fidp.surfnet.nl
Expires: di 04 nov 2014 09:17:28 CET
Expires raw: 1415089048
Send for: Any type of connection
Send for raw: false
Created: do 03 apr 2014 10:38:41 CEST
Created raw: 1396514320920783
Last accessed: ma 04 aug 2014 17:08:39 CEST
Last accessed raw: 1407164918665488
HTTP only: No
HTTP only raw: false
This domain only: No
This domain only raw: false
Policy: no information available
Policy raw: 0
Status: no information available

Status raw: 0

Host: engine.surfconext.nl
Name: selectedIdp
Path: /authentication/idp/single-sign-on/
Content: https%3A%2F%2Fidp.surfnet.nl
Content raw: https%3A%2F%2Fidp.surfnet.nl
Expires: di 04 nov 2014 10:29:22 CET
Expires raw: 1415093362
Send for: Any type of connection
Send for raw: false
Created: do 03 apr 2014 14:46:40 CEST
Created raw: 1396529200317684
Last accessed: di 05 aug 2014 09:36:51 CEST
Last accessed raw: 1407224210813410
HTTP only: No
HTTP only raw: false
This domain only: No
This domain only raw: false
Policy: no information available
Policy raw: 0
Status: no information available

Status raw: 0

Host: engine.surfconext.nl
Name: selectedIdp
Path: /authentication/idp/single-sign-on/key:20140505/
Content: http%3A%2F%2Fadfs.stenden.com%2Fadfs%2Fservices%2Ftrust
Content raw: http%3A%2F%2Fadfs.stenden.com%2Fadfs%2Fservices%2Ftrust
Expires: vr 31 okt 2014 13:34:06 CET
Expires raw: 1414758846
Send for: Any type of connection
Send for raw: false
Created: ma 21 jul 2014 14:02:04 CEST
Created raw: 1405944124474926
Last accessed: di 05 aug 2014 09:36:51 CEST
Last accessed raw: 1407224210813410
HTTP only: No
HTTP only raw: false
This domain only: No
This domain only raw: false
Policy: no information available
Policy raw: 0
Status: no information available

Status raw: 0

Host: engine.surfconext.nl
Name: selectedIdp
Path: /authentication/idp/single-sign-on/vo:managementvo/
Content: https%3A%2F%2Fidp.surfnet.nl
Content raw: https%3A%2F%2Fidp.surfnet.nl
Expires: za 25 okt 2014 14:10:30 CEST
Expires raw: 1414239030
Send for: Any type of connection
Send for raw: false
Created: di 06 mei 2014 17:22:30 CEST
Created raw: 1399389750323423
Last accessed: do 31 jul 2014 14:16:36 CEST
Last accessed raw: 1406808995821722
HTTP only: No
HTTP only raw: false
This domain only: No
This domain only raw: false
Policy: no information available
Policy raw: 0
Status: no information available

Status raw: 0

In the currently release EB, there is a problem with signature verification of redirect requests, causing verification of (at least) AuthnRequests without RelayState to fail.

This is due to improper canonicalization. The SAML Binding Spec (http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf) says in 3.4.4.1, lines 601-603, to include the RelayState in the canonicalization only "if present". However, Corto always includes the RelayState parameter in the signature verification (at least in version 3.8.2), see library/EngineBlock/Corto/Module/Bindings.php line 544. Any request without RelayState will thus fail signature validation.

We should check if this is fixed in recent versions of EB.

It seems that when a user has authenticated at an IDP, (s)he is reprovisioned in the local LDAP, even when there is no change in attributes. See EngineBlock_UserDirectory registerUser() where _updateUser() is always called on existing users. This results in unnecessary writes to the LDAP (which is optimised for reads).

EB should check existing entries for changes before updating in order to reduce the number of LDAP writes.

This is perhaps a more general version of #56. When users/administrators encounter an EB error message, they turn to the conext administrators to ask for help/more details. With many of these error types, e.g. 'Invalid IdP response', but also for example 'required attributes missing', we turn to the logs to help them find the cause but there only find the exact amount of information they already got. This while the code itself usually can discern more concrete causes than are displayed to the user.

Two examples follow.

User encounters 'Invalid IdP response'. Log mentions nothing more than 'Invalid IdP response'. However, several places in the code can trigger this error, and at those points actually add useful information. It's for example triggered with the string 'Validation of received messages enabled, but no signature found on message., but with a different text when the IdP's time is set incorrectly. It would be very useful for us to know that the latter is the cause.

A similar case is the error 'missing required fields' which talks about UID or schacHomeOrganization are missing. The logs show no extra info. However, the code (in https://github.com/OpenConext/OpenConext-engineblock/blob/master/library/EngineBlock/Corto/Filter/Command/ValidateRequiredAttributes.php) generates all kinds of informative strings: 'has too many values', 'is reserved', 'is not a valid hostname', etc. I would love to see those logged so that if someone comes to me with the error screen, I can tell them the cause immediately instead of starting a debugging process.

Profile currently has the following hidden URLs (removed from the UI) for management of 3rd party OpenSocial Group Providers:

• /group-oauth/authenticate/[provider]
• /group-oauth/consume/[provider]?oauth_token=[request-token]
• /group-oauth/revoke?provider=[provider]
• /delete-oauth-consent?consumer_key=[consumer-key]

These have not had any use on SURFconext for at least since the 24th of June.

[boy@mgnt03 prd]$ find . | grep profile/apache_access.bz2 | xargs bzgrep -v nagios-plugins | grep -i group-oauth | sort
[boy@mgnt03 prd]$ find . | grep profile/apache_access.bz2 | xargs bzgrep -v nagios-plugins | grep -i delete-oauth-consent | sort
[boy@mgnt03 prd]$

Engine now leaves the validation of VOs that might use this group provider over to API and doesn't use this functionality at all.

As such I'm assuming this can be removed?

AMs are written in PHP and as such have complete control over EngineBlock, if someone were to gain access to the Service Registry (with something like CSRF) then it would be trivial to inject something malicious into EB.

It might be worthwile to migrate AMs to a more restricted language (that is still turing complete but specifically designed for such a purpose) like Lua: http://php.net/manual/en/book.lua.php

The current implementation of IsPassive consists of passing this value thru to the home IdP (similar to ForceAuthn).
From os-core section 3.4.1: "If [IsPassive is] 'true', the identity provider and the user agent itself MUST NOT visibly take control of the user interface from the requester and interact with the presenter in a noticeable fashion"

The implementation if IsPassive in OpenConext is not complete:

• OpenConext can show a WAYF if the user has no session, this should not happen. Instead;
• when passive is not possible OpenConext should respond with a SAML Status, since we cannot show an error to a user:
  samlp:Status
  <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder">
  <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:NoPassive" />
  /samlp:StatusCode
  /samlp:Status

Also in case of other errors we should pass a status code to the IdP.

Because OpenConext passes IsPassive to the home IdP (as it should), OpenConext should expect and be able to handle a status code from the IdP.

When one authenticates against an SP that does not have certData, no useful error is logged, only a PHP warning + stacktrace (PHP Warning: openssl_verify(): supplied key param cannot be coerced into a public key in /opt/www/engineblock-4.1.2/vendor/robrichards/xmlseclibs/xmlseclibs.php on line 514).

When certData is filled but with the wrong certificate, no error is logged at all.

Currently EngineBlock gets all it's data from the ServiceRegistry API.
This has several issues:

1. ServiceRegistry (or at least it's API) is a service critical component.
2. Potential for a 'dogpile' of requests that overwhelm the ServiceRegistry.
3. An update requires a cache flush which is expensive in terms of performance (see 2.) and this makes it so that an operator does not immediately see the effects of his / her chance.

In order to avoid this we should push the Metadata to EngineBlock. Along with increasing performance this will decouple the components architecturally and improve performance.

The internal endpoint (engine-internal.demo.openconext.org) has a /cron that allows for deprovisioning.
Unfortunately EB 3.0.0 broke this: 46c291a

Reproduce:

1. Login to SP_A
2. Login to SP_B that uses a EB SSO location with "key:" slug

The AuthnRequest that EB sends to the IdP contains an AssertionConsumerServiceURL that contains the "key:" slug. This is incorrect. The "key:" slug must never be part of the AssertionConsumerServiceURL in the AuthnRequest that EB sends to an IdP. This ACS is not published in the EB metadata and might cause problems at the IdP.

Yesterday, Henny encountered a quite annoying bug in EngineBlock, which causes certain ACL updates in SR not to be reflected in EngineBlock's internal state. I reproduced it on acc this morning (i.e. with the new EB release). I assume this is an issues in EB, but I'm not 100% sure of that.

The problem is as follows: given an SP that allows access to an IdP, which in turn blocks access to this SP (i.e., the IdP is whitelisted by the SP, but the SP is not whitelisted by the IdP). When the IdP now whitelists the SP, this is not reflected in EngineBlock (as shown by the scoped proxies/idps-metadata for example). Only when the SP makes an unrelated change to its whitelist (e.g., add a different IdP to the whitelist), the data in EngineBlock is updated, and both IdPs appear in the scoped metadata.

I guess this is a bit hard to follow, so to reproduce this on acc:

• take a random SP in the SR on ACC and make sure it is connected to two IdPs that allow access and one IdP that disallows access (see screenshot: the FrKoIdP is the one we're interested in here).
  
  Flush, and fetch the scoped metadata of the SP:

[bas@miranda]~> curl -s 'https://engine.acc.surfconext.nl/authentication/proxy/idps-metadata?sp-entity-id=https://mfsp.gadgets.surfconext.nl/getdai/' | xpath '//md:EntityDescriptor/@entityID'
  Found 3 nodes:
  -- NODE --
   entityID="https://mfsp.gadgets.surfconext.nl/getdai/"-- NODE --
   entityID="http://presentain.com/saml/metadata"-- NODE --
   entityID="http://suaas-gw.surfnet.nl/metadata"

This is correct: it shows the EntityDescriptors of the SP and its two accessible IdPs.

• Now add the SP to the IdP whitelist, so we get this configuration (see screenshot):
  
  One would now expect the FrKoIdP to appear in the Engineblock metadata for this SP. However, it doesn't, even if the SR entry is saved as a new revision:

[bas@miranda]~> curl -s 'https://engine.acc.surfconext.nl/authentication/proxy/idps-metadata?sp-entity-id=https://mfsp.gadgets.surfconext.nl/getdai/' | xpath '//md:EntityDescriptor/@entityID'
Found 3 nodes:
-- NODE --
 entityID="https://mfsp.gadgets.surfconext.nl/getdai/"-- NODE --
 entityID="http://presentain.com/saml/metadata"-- NODE --
 entityID="http://suaas-gw.surfnet.nl/metadata"

• Now, on the SP side, add a whitelisting for an unrelated IdP (einstein.wind.surfnet.nl in the screenshot), and flush:
  
  Now, both IdPs (einstein.wind.surfnet.nl and FrKoIdp) show up in EB:

[bas@miranda]~> curl -s 'https://engine.acc.surfconext.nl/authentication/proxy/idps-metadata?sp-entity-id=https://mfsp.gadgets.surfconext.nl/getdai/' | xpath '//md:EntityDescriptor/@entityID'
Found 5 nodes:
-- NODE --
 entityID="https://mfsp.gadgets.surfconext.nl/getdai/"-- NODE --
 entityID="https://einstein.wind.surfnet.nl/simplesaml/saml2/idp/metadata.php"-- NODE --
 entityID="https://frko.surfnetlabs.nl/simplesamlphp/saml2/idp/metadata.php"-- NODE --
 entityID="http://presentain.com/saml/metadata"-- NODE --
 entityID="http://suaas-gw.surfnet.nl/metadata"

This might seem like a small issue, but you would be mistaken: by accidentally changing an IdP from "allow all" to allowing a few specific SPs, all SPs connected to this IdP will have to be changed to fix the situation, even if the change at the IdPs side is easily reverted. This can be a lot of work, in particular if this happens with popular IdPs (e.g., the DIY-IdP, as happended yesterday).

The error logging for "invalid IdP response" message is rather skimpy. This seems to be a change introduced in this morning's release.

Early on juli 31st (Jul 31 02:05:23) EB still logged 50ish of lines of debug data, including a full dump of the SAML Response when an invalid IdP response was received. I can send you the entire thing, if you like, but I won't paste it here as it contains personal data.

After the release (for example, Jul 31 10:33:03) there were still only 4 lines left:

Jul 31 10:33:03 prd42 EBLOG[11292]: EB[nk3kqiq1h71spf1802t36j1n67][53d9ff3e203ef] [Message INFO] FLUSHING 2 LOG MESSAGES IN SESSION QUEUE (feedback page shown)
Jul 31 10:33:03 prd42 EBLOG[11292]: > QUEUED TIMESTAMP: 2014-07-31T10:33:02+02:00| EB[nk3kqiq1h71spf1802t36j1n67][53d9ff3e1f3ac] [Message INFO] Showing feedback page with message: SURFconext - Error - Invalid Idp response
Jul 31 10:33:03 prd42 EBLOG[11292]: > QUEUED TIMESTAMP: 2014-07-31T10:33:02+02:00| EB[no session][53d9ff3e1f3ac] [Message INFO] Handling incoming request: GET /authentication/feedback/received-invalid-response
Jul 31 10:33:03 prd42 EBLOG[11292]: EB[nk3kqiq1h71spf1802t36j1n67][53d9ff3e203ef] [Message INFO] END OF LOG MESSAGE QUEUE

As you can see, there is nothing there to actually diagnose the problem.

It seems that when a user has non-ASCII chars in his email address, an exception occurs somewhere in EB.
This problem manifests itself when trying to log in with the "professor2" user of the DIY-IdP. The only obvious difference between professor1 (who can log in correctly) and professor2 is the use of UTF8-chars in the email address.

EngineBlock has no concept of SP Proxying, as such it's persistent NameID algorithm, designed to give different values for different Service Providers will always give out the same NameID for a proxying SP.

• ACL / WAYF
• Attribute Manipulation
• Attribute Release Policies
• Consent
• Logging
• Persistent NameIDs

An IdP may set a SessionIndex attribute on the AuthnStatement element in an Assertion. From the spec:
"SessionIndex [Optional]
Specifies the index of a particular session between the principal identified by the subject and the authenticating authority."

The current implementation passes the SessionIndex from the authenticating IdP through the proxy to the SP: https://github.com/OpenConext/OpenConext-engineblock/blob/master/library/EngineBlock/Corto/ProxyServer.php#L586

This is a privacy issue because this allows different SP to correlate users, defeating persistent and transient NameID mechanisms.

The SessionIndex can be used for specifying a particular session in a logout. SAML Logout is not currently supported by engine.

Implementation options:

• Do no pass SessionIndex. It is optional. This might cause a problem for an SP that expect this value.
• Generate a new random SessionIndex per SP. Keep this session in the session of the user in engineblock.

Invalid metadata can be generated by EB:

<md:Organization>
        <md:OrganizationName xml:lang="en">name</md:OrganizationName>
        <md:OrganizationURL xml:lang="en">http://url</md:OrganizationURL>
    </md:Organization>

This causes some SPs (e.g. the Shib SP) to refuse the metadata.

The fragment above is not valid according to the XSD:

<complexType name="OrganizationType">
    <sequence>
        <element ref="md:Extensions" minOccurs="0"/>
        <element ref="md:OrganizationName" maxOccurs="unbounded"/>
        <element ref="md:OrganizationDisplayName" maxOccurs="unbounded"/>
        <element ref="md:OrganizationURL" maxOccurs="unbounded"/>
    </sequence>
    <anyAttribute namespace="##other" processContents="lax"/>
</complexType>

When xml<md:Organization> is present it MUST contain:

• md:OrganizationName
• md:OrganizationDisplayName
• md:OrganizationURL
  in the order given in the sequence.

The Organization element itself is optional. When not all required values are present Organization should be omitted.

When an assertion is signed with an untrusted certificate only the error "Invalid Idp response" is shown. The descriptive "template" is not added to to the message. E.g.: "
Untrusted Certificate
Signature validation of the authentication response failed. The certificate used to sign the response is not trusted.
Certificate fingerprint:
"

Refer to https://wiki.surfnet.nl/display/conextdocumentation/Error+messages+in+Engine for more information.

(From BACKLOG-1384)

Because EB now integrates tightly with SSP, it is affected by SSPs setting of the application name for syslog.

EB does not support HTTP-Artifact bindings. However, if an SP requests that regardless, EB crashes hard with a HTTP 500 error when consuming the idp assertion and, most importantly, no logging at all.

Steps:

1. Configure some SP to request HTTP-Artifact binding (for example ssp).
2. Start authentication at the SP. SP sends an AuthnRequest with Artifact binding. EB happily accepts this
3. EB presents WAYF. Select any IdP.
4. EB redirects to the IdP (with HTTP-POST binding, of course).
5. Login to any IdP.
6. EB receives assertion from IdP, displays error "It is not possible to sign in. Please try again." with HTTP 500, but no trace of anything in logs (apache error or engineblock.log).

When EB receives a request with HTTP-Artifact in step one, it might then already issue an error about this fact, and not continue the entire dance.

Nonetheless, if it decides to continue, it should at least log some kind of error in step 6.

The licensing file header for Apache-2 has not been consistently applied, it should applied or not.

In case an IdP denies a user access to a resource, this may be signaled using:

samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder"
samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:RequestDenied"

When this occurs, engine throws an error which is technically incorrect ("RequestDenied" is a valid SAML statement, not an error!) and is also not informative nor understandable by an enduser.

In case urn:oasis:names:tc:SAML:2.0:status:RequestDenied is signaled, the enduser should be told to contact the IdP, as this is not a generic error, but a specific message that the user is denied access by the IdP

We have received requests from a SP that wants their users to be able to cancel a authentication and to be returned to their SP after cancelling. The use case is a user that triggers a federated login during exploration or by accident, is then redirected to the WAYF and can't get back to the location where (s)he triggered login. SPs can offer multiple login options: social login, local (u/p, otherwise) and federated.

The way to implement the return to the SP after cancellation seems to be to sent a SAML Response with a "urn:oasis:names:tc:SAML:2.0:status:AuthnFailed" status. An open question is how many SPs handle such a message well.

Implementation:

• Add a cancel button to the WAYF screen to allow a login request from a SP to be cancelled.
• Handle a cancel from IdP. Some IdPs support this, these will return a "urn:oasis:names:tc:SAML:2.0:status:AuthnFailed" status is this case.
• Handle a cancel in the WAYF or from an IdP by returning a "urn:oasis:names:tc:SAML:2.0:status:AuthnFailed" status to the SP.

EB contains code in several places where name related attributes (e.g. commonname, displayname, commonname, surname) attributes are created when the IdP does not provide one of these attributes. We should not do this. It is the IdP that is authoritative for these attributes, not OpenConext. In many cases the values of the created attributes will not be what is desired. EB itself does not require these attributes to function, other parts of OpenConext (Grouper, teams though the LDAP) currently do. The LDAP schema used requires sn and cn because the entries used have classes inetOrgPerson and organizationalPerson.

Since OpenConext requires cn and sn to function these we should either make these attributes mandatory to IdPs and enforce this by providing a (friendly) error to the user during login or remove the requirement. The first option is relatively simple to implement.

Code creating attributes in LDAP:
https://github.com/OpenConext/OpenConext-engineblock/blob/develop/library/EngineBlock/UserDirectory.php#L233

The current WAYF screen when fed to https://validator.w3.org gives many errors.

Most can be 'solved' by changing doctype to HTML5; so we should probably switch the doctype to start. Then a few minor ones are left which may be easy to fix.

I receive this email when requesting my attributes per mail from the debug page:

IdP
===
Name               SURFnet bv
Entity ID          https://idp.surfnet.nl
Workflow Status:   prodaccepted

SAML2 Subject
=============
NameID             Array

On the debug page itself it shows fine.

See #21

The EB SingleLogoutService Location contains the "key:" slug. Using this SLO results in a 404 on EB. Since the SLO processing does not depend on the signing key, the key slug should never be part of the SLO location.

If an AuthnRequest has an ACSUrl but no ProtocolBinding Engine (since 4.0) gives an error.
It should ignore the ACSUrl or ProtocolBinding.

Summary

• Switch back from Response signing to Assertion signing.
• Add AuthenticatingAuthority
• Make sure attributes set the NameFormat

Full
When replaying a response and analyzing the differences we found the following:

1. Missing: encoding="UTF-8"
   No problem, this is the default encoding anyway (as long as the XML doesn't start with a byte order mark character).
2. Changed: ID, IssueInstant, InResponseTo.
   TODO Boy: Time en Id generation mock should be configured correctly when replaying
3. Added: Response Destination.
   EngineBlock bug that is fixed in the new version. Nice.
4. Changed: Response Signing i.p..v Assertion Signing
   EB has switched from Response signing to Assertion signing.
   TODO: Should switch back to Response signing.
5. Added: Extra namespaces: xsi, xs
   No problem.
6. Changed: Attribute ordering
   Doesn't matter, XML attribute ordering is insignificant.
7. Note: uses the same signing algorithms Corto-EB
8. Added: Key that was used for signing.
   Nice!
9. Missing: AuthenticatingAuthority
   TODO should be added
10. Missing: NameFormat.
    TODO should be added
11. Added: xsi:type
    Nice, shouldn't make a difference though.
12. Missing: License info
    Correct, this was a change.

The engine IdP debug page (https://engine.demo.openconext.org/authentication/sp/debug) has a few bigger and smaller issues, also see attached screenshot

1. An image seems to be missing in the top left
2. When using an IdP that provides urn:OID attributes only, like e.g. surfnets DIY IdP, the debug page incorrectly reports various attributes (I assume UID and SHO) cannot be validated, however login in connected services works as engine does correctly interpret the right urn:OID attributes.
3. Various urn:OID attributes are not mapped to normal, descriptive displaynames

To reproduce, login via the DIY IdP with user student5 pass: student5

In EB 4.1.5, sending a debug email now fails with the following error:

A very serious error occurred, it has been logged and sent to the administrator.

ERROR:

array (
  'type' => 1,
  'message' => 'Call to undefined method EngineBlock_Corto_ProxyServer::layout()',
  'file' => '/opt/www/engineblock-4.1.5/library/EngineBlock/Corto/Module/Service/SingleSignOn.php',
  'line' => 446,
)

The layout() method has been removed in 7ca8a08.

From issue #37 :

"Allocating huge blocks of memory like this may facilitate denial-of-service attacks? (and I think attachments should not be dumped to syslog :-)"

• Missing information (see screenshot)
• No evidence in the engineblock log (No "Redirecting to feedback page")
  

Currently, when a user tries to login to a SP with which the IdP has no connection (i.e. the user / IdP is not authorized) *Conext displays an error. This error is not very user friendly. It would be nice if these errors would be improved, i.e. telling the user his IdP doesn't have access to this service and maybe even what to do if he would like to access the service. Also, hide the technical stuff below an accordion (collapsible panel) or something.

It would be even better if *Conext could see if it's an eduGAIN SP or not, to display a specific error message.

The engine-internal endpoint is no longer used.
Remove all associated software.

The home IdP of a user can respond with a SAML Status element with a StatusCode other than "urn:oasis:names:tc:SAML:2.0:status:Success".

We need to handle this better.

• Show status to user in readable form. See saml-core-2.0-os section 3.2.2.2 for a more readable version.
• Some status code require action form engine:
• AuthnFailed : Typically sent when a user chooses cancel on the IdP. We should forward status to SP.
• NoPassive : For passive request: Forward status to SP.
• Optional StatusMessage: Show in message to user

RequestDenied
AuthnFailed

During the install process simplesamlphp v 1.9.0 is installed, however, the current release is v 1.11.0
Where is the version set?

When you view your profile at https://profile and have an attribute with < in it, it will not render properly because attribute names and values are not properly escaped before being output.

I do not believe this is a real XSS issue since (a) it's normally difficult to control the output of your IdP's attributes, and (b) for those IdP's where you do have control over your attribute values, you could only attack yourself.

Nonetheless, this should be fixed by adding appropriate html escaping in application/modules/Profile/View/Index/Index.phtml.

The fix for issue #58 was not correct and needs to be reverted. The issue was invalid so at this point no alternative fix is needed.

With an unknown issuer in an AuthN request the following error is logged:
EB[ea20i2lnc5gu6sfnns3mbgse13][52f4aa030268e] [Message ERR] array_merge(): Argument #2 is not an array [/opt/www/engineblock-3.8.2/application/modules/Authentication/View/Feedback/UnknownIssuer.phtml:47]
EB[no session][52f4aa030268e][DUMP 'trace' (1/1)]!CHUNKSTART> #0 [internal function]: EngineBlock_Application_ErrorHandler->error(2, 'array_merge(): ...', '/opt/www/engine...', 47, Array)
#1 /opt/www/engineblock-3.8.2/application/modules/Authentication/View/Feedback/UnknownIssuer.phtml(47): array_merge(Array, NULL)
#2 /opt/www/engineblock-3.8.2/library/EngineBlock/View.php(49): require('/opt/www/engine...')
#3 /opt/www/engineblock-3.8.2/library/EngineBlock/Controller/Abstract.php(79): EngineBlock_View->render('/opt/www/engine...')
#4 /opt/www/engineblock-3.8.2/library/EngineBlock/Controller/Abstract.php(72): EngineBlock_Controller_Abstract->renderAction('UnknownIssuer')
#5 /opt/www/engineblock-3.8.2/library/EngineBlock/Dispatcher.php(90): EngineBlock_Controller_Abstract->handleAction('UnknownIssuer', Array)
#6 /opt/www/engineblock-3.8.2/library/EngineBlock/Dispatcher.php(66): EngineBlock_Dispatcher->_dispatch('/authentication...')
#7 /opt/www/e

EB[no session][52f4aa030268e][DUMP 'trace' (1/1)]!CHUNKEND>ngineblock-3.8.2/www/authentication/index.php(36): EngineBlock_Dispatcher->dispatch()
#8 {main}

EB[ea20i2lnc5gu6sfnns3mbgse13][52f4aa030325e] [Message INFO] END OF LOG MESSAGE QUEUE

The resulting Feedback page does not contain any information, only the default template containing: Error - Unknown application..

Currently, if an IdP updates its certificate without notifying SURFconext, users are shown the "Invalid Idp response" error message.
It would be nice if the error message for this specific case (SAML Response signed by unknown/mismatched key) would be more specific.

Some SPs report missing the RelayState.

The metadata representation in EngineBlock of an SP with multiple ACS locations is represented differently than it is configured in the service registry Janus.

E.g. the ACS definition in JANUS is:

<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://www.isiknowledge.com/?auth=Shibboleth" index="3"/>
<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://www.webofknowledge.com/?auth=Shibboleth" index="4"/>
<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://admin-router.webofknowledge.com/?auth=Shibboleth" index="7"/>
<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://admin-router.webofknowledge.com/?auth=Shibboleth" index="8"/>
<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://cortellis.thomsonreuterslifesciences.com/ngg/sso/saml2/responseGateway.do" index="10"/>    

Note: the index is: 3,4,7,8 & 10

while the metadata representation in EngineBlock is:

<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://www.isiknowledge.com/?auth=Shibboleth" index="0"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://www.webofknowledge.com/?auth=Shibboleth" index="1"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://admin-router.webofknowledge.com/?auth=Shibboleth" index="2"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://admin-router.webofknowledge.com/?auth=Shibboleth" index="3"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://cortellis.thomsonreuterslifesciences.com/ngg/sso/saml2/responseGateway.do" index="4"/>

Note: the index is: 1,2,3,4 & 5

For instance, a GET /authentication/proxy/idps-metadata?sp-entity-id=https://nonexistent/sp results in a 500 Internal Server Error

Apache-Error: [file ...] [line ...] [level 3] PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 251402241 bytes) in .../engineblock-3.8.3/library/EngineBlock/Log.php on line 57

See:
https://github.com/OpenConext/OpenConext-engineblock/blob/master/library/EngineBlock/Log.php#L60

The issue is twofold: retrieving metadata for a non-existing SP should result in a 4xx error, and allocating huge blocks of memory like this may facilitate denial-of-service attacks? (and I think attachments should not be dumped to syslog :-)

SP's that use the transparent idp endpoint (that is, the one with the md5 in it) should get assertions that list engine as the issuer, not the remote IdP. This in contrast with SP's that have the coin:transparant_issuer (sic?) option set. This is the behaviour that 3.8.5 exhibited.