From [email protected] on October 15, 2012 21:17:28

This patch allows SReg and AX requests. It uses AttributeMap to map attributes from the authentication source. It uses the 'authproc.idp' array in config.php and 'authproc' array inside module_openidProvider.php. For example to obtain email from authentication source, you could add

'authproc' => array(
    10 => array(
        'class'=>'core:AttributeMap', 
        'mail'=>array('email', ' http://axschema.org/contact/email' )
    )
)

to your module_openidProvider.php.

Attachment: Server.php.patch

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=518

From [email protected] on February 08, 2012 23:23:03

Add support for conditional HTTP GET requests in the aggregator module. This would enable clients to efficiently poll for aggregated metadata.
Could be implemented using Last-Modified/If-Modified-Since and ETag/If-None-Match headers.
The aggregator2 module seems to already have some caching logic onboard, so it makes sense to implement it there.

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=474

From [email protected] on October 27, 2010 12:33:50

I'm developing a project which uses simplesamlphp. I'm developing, among other things, a custom authsource. It would be great if I can create a project in my own SVN server that uses simplesamlphp as an svn external, so I can easily keep up to date with simplesamlphp's development.

This is currently not possible because all modules, metadata and configurations are always stored in a subdir of simplesamlphp; it would be great if this could be externalized to directories outside of the main simplesamlphp directory, so an svn external can easily do a drop in of simplesamlphp into an existing svn project.

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=349

From [email protected] on February 16, 2012 08:14:20

We should update the library in modules/authYubiKey/libextinc to the latest version from http://code.google.com/p/php-yubico/

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=479

From [email protected] on July 16, 2013 07:07:26

I was getting this error:

""
Declaration of sspmod_openid_StateStore::storeAssociation() should be compatible with >Auth_OpenID_OpenIDStore::storeAssociation($server_url, $association) >[APP/simplesamlphp/modules/openid/lib/StateStore.php, line 14]

looking at the code I have noticed that in class "stateStore", line 167 of version: simplesamlphp-1.11.0, the method definition is:

public function storeAssociation($server_url, Auth_OpenID_Association $association) {
...
}

and it should be:

public function storeAssociation($server_url, $association) {
...
}

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=556

From [email protected] on October 03, 2012 10:07:10

To support sending the request through a proxy, we should use SimpleSAML_Utilities::fetch() when sending requests from this class.

Unfortunately, it will require a bit of work in order to propagate errors correctly from SimpleSAML_Utilities::fetch()

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=515

From [email protected] on December 09, 2013 16:27:32

It should be possible to export the list of supported NameID formats in the generated metadata without explicitly telling with the NameIDFormat option (which currently supports only one format). By just looking into the NameID generation filters (1) generally available, an IdP should be able to tell which formats it supports, so there's no need to manually specify them.

The current configuration mechanism is error prone and may lead to configurations such as an IdP claiming to support only the persistent format, but actually not supporting it because there's no generation filter in place. The NameIDFormat option could be kept as an array that filters the list of formats supported, namely to remove transient support.

On the SP side, the NameIDFormat directive should be an array specifying the list of formats supported, mainly for metadata generation.

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=604

From [email protected] on November 25, 2009 15:21:22

The statistics processing currently causes warnings:

SimpleSAML_Error_Exception: Error 2048 - mktime(): The is_dst parameter is deprecated
Backtrace:
7 .../www/_include.php:48 (SimpleSAML_error_handler)
6 builtin
5 .../modules/statistics/lib/DateHandlerMonth.php:35
(sspmod_statistics_DateHandlerMonth::fromSlot)
4 .../modules/statistics/lib/Aggregator.php:246
(sspmod_statistics_Aggregator::store)
3 .../modules/statistics/hooks/hook_cron.php:28 (statistics_hook_cron)
2 .../lib/SimpleSAML/Module.php:176 (SimpleSAML_Module::callHooks)
1 .../modules/cron/www/cron.php:28 (require)
0 .../www/module.php:137 (N/A)

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=244

From [email protected] on January 29, 2010 15:39:54

Hi,

The current Metadata Converter interface is a large textarea. This works
fine for small sets of metadata, but some federations have sets that exceed
the 200kB. This is problematic to easily copy-paste. Besides that, making
large POST requests in this way can lead to errors when the PHP Suhosin
module is installed.

I would like to have a file upload field where I can upload the metadata
file. An alternative may be an URL-grab feature where you paste the URL of
the metadata you want to parse, but this may have some unforeseen security
implications, so may perhaps not be a great idea.

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=282

This metadata handler has shown itself to not work in practice, so it is better to just remove it. It shouldn't be used for any production setups in any case.

From [email protected] on June 19, 2009 07:51:08

Hi,
There is the very simple patch which enables additional ldap filtering.
Maybe it will be usefull.
Thanks,
Janusz Ulanowski

Attachment: filtering.patch

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=172

From [email protected] on January 29, 2009 09:24:18

Support AuthnContext on the IdP.

Should be possible to map AuthnContext-s to different Authentication Sources.

From an Authenticaiton Source it should also be possible to set
AuthnContext that is reflected in the AuthN:Response.

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=144

From [email protected] on November 27, 2013 09:53:46

What steps will reproduce the problem?

1. Configure an IdP which uses the 'urn:oasis:names:tc:SAML:2.0:cm:sender-vouches' SubjectConfirmation-Method
2. Use the Authentication test page

I would expect to be authenticated, but get an exception:

Backtrace:
0 /var/simplesamlphp/www/module.php:180 (N/A)
Caused by: SimpleSAML_Error_Exception: Error validating SubjectConfirmation in Assertion: Invalid Method on SubjectConfirmation: 'urn:oasis:names:tc:SAML:2.0:cm:sender-vouches'
Backtrace:
3 /var/simplesamlphp/modules/saml/lib/Message.php:694 (sspmod_saml_Message::processAssertion)
2 /var/simplesamlphp/modules/saml/lib/Message.php:528 (sspmod_saml_Message::processResponse)
1 /var/simplesamlphp/modules/saml/www/sp/saml2-acs.php:81 (require)
0 /var/simplesamlphp/www/module.php:135 (N/A) What version of the product are you using? On what >operating system? 1.11.0 on Ubuntu 13.10.

This is a follow-up for Issue #333 .

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=600

From [email protected] on July 18, 2009 10:17:19

Document was updated on 2009-07-18, but Andreas is leaving on vacation and do not have time
for proper testing of the guide.

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=177

From [email protected] on November 29, 2010 10:40:01

We need to support stuffing the idpdisc:DiscoveryResponse in metadata; and more importantly in the discovery service, by an optional configuration, restrict the receivers of responses from the discovrey service to hostnames listed in metadata (of trusted SPs).

As specified in the IdP Discovery profile: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery.pdf

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=363

From [email protected] on February 05, 2010 09:43:38

The Subject element does not require a NameID.

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=289

From [email protected] on March 05, 2009 10:21:44

Use -1 in google charts

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=154

From [email protected] on May 09, 2012 14:25:59

To verify the signature on the metadata, the validateFingerprint option must be configured in the metarefresh module. Thus the configuration must be changed whenever the federation operator's verification certificate changes EVEN IF THE KEY BOUND TO THE CERTIFICATE DOES NOT CHANGE. An organization that owns dozens of entities would have to touch all of those entities in response to such a certificate renewal.

In the InCommon Federation, this is a regular occurrence. The FedOp has used the same private signing key for over 8 years, but the verification certificate containing the corresponding public key has been renewed often. The next such transition will occur on May 14, 2012. All simpleSAMLphp deployments in the InCommon Federation must replace the "old" fingerprint with the "new" fingerprint sometime between Friday, May 11 (after refreshing metadata) and Monday, May 14 (before refreshing metadata), otherwise their metadata refresh processes will break.

The best solution is to make the verification certificate available to simpleSAMLphp such that the key can be extracted and used to verify the signature on the metadata. This is what Shibboleth does in fact. All Shibboleth deployments are immune to this bug.

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=494

From [email protected] on January 28, 2013 20:39:06

What steps will reproduce the problem?

1. simplesamlphp supports OpenID but doesn't allow restricting what websites (pseudo-SPs) can use it
3. What is the expected output? What do you see instead? What version of the product are you using? On what operating system? Please provide any additional information below. Not a bug but a feature request. I can imagine organizations using SAML wanting to support OpenID - but only if it can be restricted to websites in a similar way to SAML

A SAML IdP allows an organization to "trust" certain SPs with details from its internal Identity Management system. As such it requires a formal agreement between the two entities. Allowing OpenID to be treated in the same way seems to me to be something some organizations would find attractive.

Jason

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=536

From [email protected] on June 15, 2012 18:04:38

Should have separate statistics events for:

• Successful authentication (may or may not be tied to a SSO event)
• Failed authentication

It would be an advantage if the failed authentication events would allow us to see the difference between invalid username, incorrect password, and other errors.

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=500

From [email protected] on January 26, 2010 12:45:07

Remove support for deprecated dictionary format

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=274

PHP with FastCGI has shown itself to be problematic wrt. PATH_INFO, so making SimpleSAMLphp work on Nginx is problematic. Maybe we can use other variables?

From [email protected] on January 26, 2010 12:45:37

Remove depdecated SAML SP code, in www/saml2/sp and www/shib13/sp

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=275

From [email protected] on December 17, 2010 08:54:20

jQuery UI isn't used for any advanced features, so we should be able to remove it. Doing that will make it easier to keep jQuery versions up to date.

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=372

From [email protected] on December 22, 2010 14:03:41

If the user closes the browser after or during logout, but saves the tabs that the browser has open, the user will receive an error message about missing state information when starting the browser again.

It would be better to just display a "you have been logged out" message in those cases.

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=375

From [email protected] on March 26, 2010 11:22:52

The IdP should check which NameIDFormat the SP requests, and try to send
back that format.

It must also be possible to limit which NameIDFormats the IdP is willing
to give to various SPs.

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=303

From [email protected] on November 06, 2013 10:28:00

What steps will reproduce the problem? 1. use of core:AttributeLimit can only match requested attributes - doesn't support required (isRequire="true") or the flexibility of entity-category.
2. attached patches get us a lot closer to that mark :-)
3. clearly looking forward to a range of feedback on this patch
4. this is not meant to be feature complete with implementations in parallel products but does cover many of the general purpose cases. What is the expected output? What do you see instead? the attached patches allow you to specify filter rules within config-attributelimit.php that match on EntityID, RegistrationAuthority and/or EntityCategory. This does NOT support arbitrary matching on EntityAttributes. What version of the product are you using? On what operating system? r3288 Please provide any additional information below. The patches relate to:

• modules/core/lib/Auth/Process/AttributeLimit.php
• config-templates/config-attributelimit.php
  an example config-templates file is attached (config-attributelimit.php)
• lib/SimpleSAML/Metadata/SAMLParser.php
• modules/saml/www/sp/metadata.php

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=591

From [email protected] on February 15, 2011 14:26:52

Hi Olav, Andreas and the rest of you

I have a situation which to me looks like a bug. The scenario is as follows:

1. A service sends a request to a simpleSAMLphp instance containing three IDPList[] url parameters.

2. The simpleSAMLphp correctly shows only the three IdPs.

3. If I then want to change the language, instead of being presented with the same choice in another language, I’m send to the IdP referenced last of the IDPList[] URL parameters.

My observation is that all the URLs behind the alternate language links only contains ONE IDPList[] parameter.

Possible explanation:

These links are created with SimpleSAML_Utillities::addURLParameter which uses SimpleSAML_Utillities::parseQueryString. The latter method converts the query string to an array where the keys are the parameter names. As the IDPList functionality is based upon having multiple IDPList parameters (all with the same name), we end up loosing all but one of these parameters. (but gaining a &language=XX :-)

To correct this bug, it looks to me like the whole IDPList system in involved. Therefore I unfortunately don’t think I can make an easy work-around.

I’m looking forward to hear your opinion on this issue.

Regards,

Per Møldrup-Dalum
Digital Preservation Technology
State and University Library
Denmark

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=390

From [email protected] on February 03, 2010 15:22:53

IsPassive should be passed through the bridge. AS discussed in meeting in Copenhagen.

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=286

From hege%[email protected] on March 23, 2010 14:56:32

Shibboleth-based federations often use scopes to limit the impact of
compromised or bad-behaving IdPs trying to impersonate other IdPs users. In
order to support that, SimpleSAMLphp SP code should filter scoped attributes
if the IdP metadata contains the proprietary Shibboleth 'scope' extension.

I'll try to implement this in a new module, if this concept is acceptable.

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=300

From [email protected] on October 22, 2013 15:58:37

Just throwing it out there, moving development to GitHub could help with contributions (Pull Requests) and allow people to fork in order to add their configuration files.

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=576

From [email protected] on January 26, 2010 11:31:23

Remove www/ws-fed directory.

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=267

From [email protected] on July 04, 2012 14:36:49

The attribute values are not sorted before the attribute hash is calculated in the consent module.

If you are using the attribute values in consent, that the attribute hash will change if the order of the attribute values change but the actual values are the same.

The values should be sorted, so the attribute hash persists even if the order of the attribute values change.

The following will fis this:

Index: modules/consent/lib/Auth/Process/Consent.php
===================================================================
--- modules/consent/lib/Auth/Process/Consent.php    ( revision 3128 )
+++ modules/consent/lib/Auth/Process/Consent.php    (working copy)
@@ -309,6 +309,9 @@
     {
         $hashBase = null;  
         if ($includeValues) {
+            foreach ($attributes AS &$values) {
+                sort($values);
+            }
             ksort($attributes);
             $hashBase = serialize($attributes);
         } else {

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=505

From [email protected] on January 26, 2010 12:45:01

Remove www/auth and deprecated authentication module API

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=273

From [email protected] on December 20, 2012 14:09:31

What steps will reproduce the problem? 1. Configure saml20-idp-hosted.php and put 'redirect.sign' => TRUE
2. Get the metadata for your IdP What is the expected output? What do you see instead? Expected output:
<md:IDPSSODescriptor ... WantAuthnRequestsSigned="true">

Actual output:
<md:IDPSSODescriptor ... > What version of the product are you using? On what operating system? This can be reproduced with SSP 1.10.0 and trunk Please provide any additional information below. The bug is due to a typo and also in the metadata.php view, which is not passing this option to the Metadata/SAMLBuilder.php

Attached is a very simple patch that solves this issue.

Attachment: wantauthnrequestssigned-metadata.patch

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=528

From [email protected] on May 20, 2010 13:05:56

There is now two different versions of jQuery in simpleSAMLphp. It would be
better to only support the latest version.

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=316

From [email protected] on July 23, 2012 09:08:52

Should log statistics every time it shows the warning. The statistics data should include both the SP entityID and IdP entityID.

• Use new statistics infrastructure (SimpleSAML_Stats).
• Fields for entityID should be named "spEntityID" and "idpEntityID".
• Should also include the time since the last login.

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=508

This option can be set on destination and source metadata, but relying on this attribute makes filters rather confusing. It would be better to specifically list the attribute to be used as an user identifier in the applicable filters.

From [email protected] on January 26, 2010 12:46:37

As soon as a module repository is ready, we should consider all modules, and move out some of the
more experimental modules such as infocard to the repository.

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=276

From [email protected] on June 21, 2010 08:44:23

Should be possible to specify a custom filter for LDAP search.

See: http://groups.google.com/group/simplesamlphp/browse_thread/thread/3239315ccfb4aeee

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=325

From [email protected] on March 16, 2010 17:53:35

The simplesamlphp OAuthDataStore implementation

sspmod_oauth_OAuthStore

assigns a validity to OAuth access tokens upon inserting them into the DB.
By default that is 24 hours, like here

$this->store->set('access', $token->key, $consumer->key, $token,
$this->config->getValue('accessTokenDuration', 60*60*24) );

However, upon looking up the access tokens, that validity is not checked in
the sspmod_core_Storage_SQLPermanentStorage, giving OAuth access tokens an
indefinite validity.

A very fast fix is adding

$this->store->removeExpired();

to the beginning of function lookup_token($consumer, $token_type, $token).

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=298

From [email protected] on September 22, 2010 11:38:44

As the SAML functionality is moved out in modules, the enabled traffic lights are not longer as valid as they once were. We shuold remove this box from the UI.

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=341

From [email protected] on November 23, 2011 17:46:26

Mark this one as low priority. Hope I'm not bugging you too much, I just like to help open source projects that I use, return the favor. :)

I use a IDE product called phpStorm, which has deep code insight. As I develop custom modules, the IDE reports many errors of wrong data types. Same happens when I look at SimpleSAMLphp files. The issue is missing datatypes in the doc block @param lines. Would you care if I go through and fix these with a patch? It would be helpful so I don't have to fix them when upgrading SimpleSAMLphp. Just want to check before putting the effort into such a big task. Thanks http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_tags.param.pkg.html

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=458

From [email protected] on December 07, 2011 12:37:41

What steps will reproduce the problem? 1. I will extends the sspmod_sqlauth_Auth_Source_SQL class and use my own password check method What version of the product are you using? On what operating system? trunk Please provide any additional information below. At the moment it is not possible to extends the sspmod_sqlauth_Auth_Source_SQL class and override only one method to validate the password.
So i have rewrite the class. It has a little bc break you must change the sql query it is documented in the docs see patch only remove the password from where and add it to the selected fields.

No it is possible to extends the class and only override the checkPassword() method.

Also it has now a filterAttributes method.

Attachment: sqlauth_extenable.patch

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=462

From [email protected] on December 26, 2012 16:15:29

Hi,

I want to store the metadata entries (particularly the saml20-idp-remote and saml20-sp-remote) in an SQL database. I didn't find any (publicly) available implementation for this so I wrote my own. Unfortunately it does not seem to be possible to do this as a module, but needs to be implemented in core.

It is rough around the edges and documentation is not really available, but I wanted to get this code out there.

The reason for doing this is to make it possible to have an easy management API. If the API only needs to interact with JSON objects in the database it becomes very easy to write a REST API and use a HTML5 + JavaScript client side app to do the management. As most configuration for SPs and IdPs can be done through the metadata for the respective types it can most likely be a very simple JANUS replacement.

The module stores a json_encode of the existing metadata format in the database, keeping stuff as simple as possible. The getMetadataSet function is a bit heavy still, but I hope this call is not used during regular IdP/SP interaction.

The configuration takes place in config/config.php, e.g.:

        'metadata.sources' => array(
                array('type' => 'flatfile'),
                array('type' => 'pdo',
                      'usePersistentConnection' => FALSE,
                      'dsn' => 'sqlite:/tmp/ssp.sqlite',
                      'username' => NULL,
                      'password' => NULL,
                ),
        ),

See the attached patch to trunk.

To add the entries to the database use the following snippet for IdPs, it just imports the existing entries:

require_once "saml20-idp-remote.php";
foreach($metadata as $k => $v) {
    echo "INSERT INTO `saml20-idp-remote` ('entityId', 'entityData') VALUES ('" . $k . "','" . json_encode($v) . "');" . PHP_EOL;
}

Or this one for SPs:

require_once "saml20-sp-remote.php";

foreach($metadata as $k => $v) {
    echo "INSERT INTO `saml20-sp-remote` ('entityId', 'entityData') VALUES ('" . $k . "','" . json_encode($v) . "');" . PHP_EOL;
}

Attachment: simplesamlphp-add-pdo-metadata-source.diff

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=529

This option makes it possible to override the configuration per host, but it has never been documented, and it can be replaced with simple PHP code in the configuration, so I'd remove this option for 2.0.

From [email protected] on December 21, 2010 13:46:14

Currently, only the SAML 2.0 IdP supports different NameID formats. We should also add support for those in SAML 1.1.

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=373

From [email protected] on January 21, 2010 17:24:19

Adding friendly translation of schac attributes (EN and ES) to
simplesamlphp dictionary.

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=260

From [email protected] on July 26, 2013 10:28:14

I've created a simpleSAMLphp module to integrate with VOOT services protected with OAuth 2.0. The module retrieves group membership information from the VOOT provider and adds the groups to the SAML attributes.

The code currently can be found here: https://github.com/fkooman/ssp-voot-groups There are some releases available and they work fine for our (OpenConext/SURFconext) VOOT services.

I would like to add this module to simpleSAMLphp if there are more potential users of this module.

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=558

From [email protected] on March 23, 2010 10:07:56

simplesamlphp's OAuth module defines an OAuthException.

Now that has a naming collission with the same class in the PHP OAuth module: http://se.php.net/manual/en/class.oauthexception.php Since PHP's OAuth module is somewhat semi-official and simplesamlphp's
OAuthException doesn't do anything, maybe the name could be changed?

Original issue: http://code.google.com/p/simplesamlphp/issues/detail?id=299