Closed GoogleCodeExporter closed 8 years ago
This patch adds metadata for the ADFS IdP. The metadata is sufficient to allow
VS 2012 Identity and Access Tool to import and setup the IdP automatically just
like a true Windows AD FS server.
This patch also adds documentation within the ADFS module on configuring the
IdP as well as how to access the metadata.
This module is currently in Production use at GoDaddy to provide an easy method
for .NET developers to consume the SimpleSAMLPHP IdP.
Original comment by Daniel.Tsosie
on 3 Feb 2014 at 5:35
lib/SAML2/Const.php b/lib/SAML2/Const.php
File was modified to add a new constant for WS-FED Schema
The following new files add xml constructs under the WS-FED schema necessary
for the ADFS IdP to identify itself as an STS for downstream applications.
lib/SAML2/XML/fed/Endpoint.php -
lib/SAML2/XML/fed/SecurityTokenServiceType.php
lib/SAML2/XML/fed/TokenTypesOffered.php
lib/SimpleSAML/Metadata/MetaDataStorageHandler.php
This file was modified to generate a proper URL to serve as the "endpoint"
within the ADFS metadata.
lib/SimpleSAML/Metadata/SAMLBuilder.php
This file had a new function added to build metadata structures regarding the
new security token constructs.
metadata-templates/adfs-idp-hosted.php
The ADFS template now references a new name2claim map. This names AD LDAP to
correspond with Microsoft Claims, allowing seemless zero configuration
integration between the IdP and the consuming applications.
modules/adfs/docs/adfs.txt
This file was added to document the process of setting up and testing the IdP,
following the same steps as the normal SAML IdP.
modules/adfs/www/idp/metadata.php
Adds a point at which the adfs idp metadata may be accessed.
attributemap/name2claim.php
Adds a map to translate AD LDAP names to Microsoft claims.
Original comment by Daniel.Tsosie
on 3 Feb 2014 at 5:51
Hi Daniel!
First, thanks a lot for this nice work!
Which version of SSP have you used to develop this patch? I see you have quite
a few references to the old lib/SAML2 directory, which is now gone and moved to
a new SAML2 external library, hosted in github (1).
The obvious thing here would be to move those changes to the new lib, but I
think it might be a bit more complicated than that. In the end, AFAIU, WS-Fed
uses SAML internally, but it's like an additional layer on top of it (you'll
have to forgive my ignorance here, but I've never got my hands on WS-Fed
before). In that case, it makes more sense IMO to have a new lib "implementing"
(so to say) WS-Fed, that internally uses the SAML2 lib, and make SSP load that
as we are doing now with all other external libs. The rest of it (docs,
metadata endpoint, claim mappings, etc) fits perfectly well in SSP as it is now.
I know this might be a non negligible amount of work (specially if you compare
to what you already have done), but in my head it doesn't make much sense to
just drop WS-Fed-related things into a pure SAML2 library...
What do you think?
(1) https://github.com/simplesamlphp/saml2
Original comment by jaim...@gmail.com
on 3 Feb 2014 at 6:25
Original comment by jaim...@gmail.com
on 9 Feb 2014 at 5:17
Original issue reported on code.google.com by
Daniel.Tsosie
on 28 Jan 2014 at 6:00Attachments: