Re: SimpleSamlPHP using ws-fed to authenticate to a window STS with a SAML 2.0 token
2,047 views
Skip to first unread message
Olav Morken
Oct 10, 2012, 7:54:28 AM10/10/12
to simple...@googlegroups.com
On Tue, Oct 09, 2012 at 18:28:00 -0700, Dimitri Kartsonas wrote:
> Hello,
>
> We are trying to use SSP in our application as a SP and authenticate to a
> Windows STS IdP.
A warning first: The WS-Federation SP support in simpleSAMLphp is not
well maitained. It hasn't been updated to use the new authentication
framework, so it is a bit different than everything else that is
present. It should in theory work, but I have not tested it for a very
long time.
> Below is the modified metadata from their site.
>
> <EntityDescriptor ID="_123"
> entityID="http://staging.xxxx.com"><RoleDescriptor
> xsi:type="fed:SecurityTokenServiceType"
> protocolSupportEnumeration="http://docs.oasis-open.org/wsfed/federation/200706"
> ServiceDescription="Security Token Service.">
> <KeyDescriptor use="signing">
> <KeyInfo>
> <X509Data><X509Certificate>6iTAN
> </X509Certificate>
> </X509Data>
> </KeyInfo>
> </KeyDescriptor>
> <fed:TokenTypesOffered>
> <fed:TokenType Uri="urn:oasis:names:tc:SAML:2.0:assertion"/>
> </fed:TokenTypesOffered>
> <fed:ClaimTypesOffered>
> <auth:ClaimType
> Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
> Optional="true"><auth:DisplayName>Name</auth:DisplayName>
> <auth:Description>The name of the subject.</auth:Description>
> </auth:ClaimType><auth:ClaimType
> Uri="http://schemas.microsoft.local/ws/2008/06/identity/claims/role"
> Optional="true">
> <auth:DisplayName>Role</auth:DisplayName><auth:Description>The role of the
> subject.</auth:Description>
> </fed:ClaimTypesOffered>
> <fed:SecurityTokenServiceEndpoint>
> <EndpointReference><Address>http://staging.xxxxx.com/</Address>
> <Metadata><Metadata>
> <wsx:MetadataSection
> Dialect="http://schemas.xmlsoap.org/ws/2004/09/mex"><wsx:MetadataReference>
> <Address>http://staging.xxxxxx//mex</Address></wsx:MetadataReference></wsx:MetadataSection></Metadata></Metadata></EndpointReference></fed:SecurityTokenServiceEndpoint><fed:PassiveRequestorEndpoint><EndpointReference><Address>http://staging.xxxx.com/</Address></EndpointReference></fed:PassiveRequestorEndpoint></RoleDescriptor><Organization><OrganizationName
> xml:lang="">xxx</OrganizationName><OrganizationDisplayName
> xml:lang="">xxx</OrganizationDisplayName></Organization><ContactPerson
> contactType="technical"><Company>xx</Company><GivenName>xxx</GivenName><SurName>xx</SurName><EmailAddress>xxxxx</EmailAddress><TelephoneNumber/></ContactPerson>
> </EntityDescriptor>
>
>
> In config.php
> we set enable.wsfed-sp => true
>
> and 'default-wsfed-idp' => 'remote',
>
> and
> 'logging.level' +>SimpleSAML_Logger::DEBUG,
> 'logging.handler' => 'file'
>
>
> In authsource.php
> 'default-sp' => array(
> 'saml:SP',
> 'privatekey' => 'Ourrsaprivkey.pem',
> 'certificate' => 'OurTest.cer'
That is for a SAML service provider. It is not used for WS-Federation.
> In wsfed-idp-remote.php
>
> $metadata['remote'] = array(
> 'prp' => 'https://staging.xxx.com',
> 'certificate' => 'their-token.cer'
> );
>
>
> We used the code from the www/example-simple/wsfed-example.php as the
> base code for our test application.
>
> We get redirected to the login page of the Windows STS and entered the
> login information but were not authenticated.
>
> I noticed the header request had the realm set to
> urn:federation:oursite.com. (In the STS our URL is 'https://oursite.com)
> Is there a way to change the request?
This comes from metadata/wsfed-sp-hosted.php. To set a custom ID,
change __DYNAMIC:1__ to the ID you want to use.
> Also, what are we missing in the configuration / setup to get authenticated
> ?
What happens instead of getting authenticated?
> Once authenticated, how can we read the claim information?
$session = SimpleSAML_Session::getInstance();
$session->getAttributes();
> Any and all help is greatly appreciated!
I cannot really offer very much help with it -- I am not familiar with
WS-Federation, so I do not know much about how it is supposed to work.
Since ADFS 2.0 supports SAML 2.0 I guess most of the community is
moving to SAML 2.0 as well.
Best regards,
Olav Morken
UNINETT / Feide
> Hello,
>
> We are trying to use SSP in our application as a SP and authenticate to a
> Windows STS IdP.
A warning first: The WS-Federation SP support in simpleSAMLphp is not
well maitained. It hasn't been updated to use the new authentication
framework, so it is a bit different than everything else that is
present. It should in theory work, but I have not tested it for a very
long time.
> Below is the modified metadata from their site.
>
> <EntityDescriptor ID="_123"
> entityID="http://staging.xxxx.com"><RoleDescriptor
> xsi:type="fed:SecurityTokenServiceType"
> protocolSupportEnumeration="http://docs.oasis-open.org/wsfed/federation/200706"
> ServiceDescription="Security Token Service.">
> <KeyDescriptor use="signing">
> <KeyInfo>
> <X509Data><X509Certificate>6iTAN
> </X509Certificate>
> </X509Data>
> </KeyInfo>
> </KeyDescriptor>
> <fed:TokenTypesOffered>
> <fed:TokenType Uri="urn:oasis:names:tc:SAML:2.0:assertion"/>
> </fed:TokenTypesOffered>
> <fed:ClaimTypesOffered>
> <auth:ClaimType
> Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
> Optional="true"><auth:DisplayName>Name</auth:DisplayName>
> <auth:Description>The name of the subject.</auth:Description>
> </auth:ClaimType><auth:ClaimType
> Uri="http://schemas.microsoft.local/ws/2008/06/identity/claims/role"
> Optional="true">
> <auth:DisplayName>Role</auth:DisplayName><auth:Description>The role of the
> subject.</auth:Description>
> </fed:ClaimTypesOffered>
> <fed:SecurityTokenServiceEndpoint>
> <EndpointReference><Address>http://staging.xxxxx.com/</Address>
> <Metadata><Metadata>
> <wsx:MetadataSection
> Dialect="http://schemas.xmlsoap.org/ws/2004/09/mex"><wsx:MetadataReference>
> <Address>http://staging.xxxxxx//mex</Address></wsx:MetadataReference></wsx:MetadataSection></Metadata></Metadata></EndpointReference></fed:SecurityTokenServiceEndpoint><fed:PassiveRequestorEndpoint><EndpointReference><Address>http://staging.xxxx.com/</Address></EndpointReference></fed:PassiveRequestorEndpoint></RoleDescriptor><Organization><OrganizationName
> xml:lang="">xxx</OrganizationName><OrganizationDisplayName
> xml:lang="">xxx</OrganizationDisplayName></Organization><ContactPerson
> contactType="technical"><Company>xx</Company><GivenName>xxx</GivenName><SurName>xx</SurName><EmailAddress>xxxxx</EmailAddress><TelephoneNumber/></ContactPerson>
> </EntityDescriptor>
>
>
> In config.php
> we set enable.wsfed-sp => true
>
> and 'default-wsfed-idp' => 'remote',
>
> and
> 'logging.level' +>SimpleSAML_Logger::DEBUG,
> 'logging.handler' => 'file'
>
>
> In authsource.php
> 'default-sp' => array(
> 'saml:SP',
> 'privatekey' => 'Ourrsaprivkey.pem',
> 'certificate' => 'OurTest.cer'
That is for a SAML service provider. It is not used for WS-Federation.
> In wsfed-idp-remote.php
>
> $metadata['remote'] = array(
> 'prp' => 'https://staging.xxx.com',
> 'certificate' => 'their-token.cer'
> );
>
>
> We used the code from the www/example-simple/wsfed-example.php as the
> base code for our test application.
>
> We get redirected to the login page of the Windows STS and entered the
> login information but were not authenticated.
>
> I noticed the header request had the realm set to
> urn:federation:oursite.com. (In the STS our URL is 'https://oursite.com)
> Is there a way to change the request?
This comes from metadata/wsfed-sp-hosted.php. To set a custom ID,
change __DYNAMIC:1__ to the ID you want to use.
> Also, what are we missing in the configuration / setup to get authenticated
> ?
What happens instead of getting authenticated?
> Once authenticated, how can we read the claim information?
$session = SimpleSAML_Session::getInstance();
$session->getAttributes();
> Any and all help is greatly appreciated!
I cannot really offer very much help with it -- I am not familiar with
WS-Federation, so I do not know much about how it is supposed to work.
Since ADFS 2.0 supports SAML 2.0 I guess most of the community is
moving to SAML 2.0 as well.
Best regards,
Olav Morken
UNINETT / Feide
Dimitri Kartsonas
Oct 10, 2012, 9:59:08 PM10/10/12
to simple...@googlegroups.com
Is authsource.php used at all for a wsfed configuration?
> In wsfed-idp-remote.php
>
> $metadata['remote'] = array(
> 'prp' => 'https://staging.xxx.com',
> 'certificate' => 'their-token.cer'
> );
>
>
> We used the code from the www/example-simple/wsfed-example.php as the
> base code for our test application.
>
> We get redirected to the login page of the Windows STS and entered the
> login information but were not authenticated.
>
> I noticed the header request had the realm set to
> urn:federation:oursite.com. (In the STS our URL is 'https://oursite.com)
> Is there a way to change the request?
This comes from metadata/wsfed-sp-hosted.php. To set a custom ID,
change __DYNAMIC:1__ to the ID you want to use.
Great - it took me some time to understand what you meant. Below is the configuration from or wsfed-SP-hosted:
$metadata['https://oursite.com'] = array(
'host' => 'oursite.com',
'privatekey' => 'ourPrivateKey.pem',
'certificate' => 'ourPublicKey.cer',
Two questions:
1. Are the key settings correct?
2. What additional parameters should be set for wsfed?
$metadata['https://oursite.com'] = array(
'host' => 'oursite.com',
'privatekey' => 'ourPrivateKey.pem',
'certificate' => 'ourPublicKey.cer',
Two questions:
1. Are the key settings correct?
2. What additional parameters should be set for wsfed?
> Also, what are we missing in the configuration / setup to get authenticated
> ?
What happens instead of getting authenticated?
When we enter the login information at the remote Idp the page disappears and redirects back to our site. I traced the exchange using fiddler and the session bounces back and forth between our site and the Idp. the following is the only information captured in the logfile:
INFO [c7388fcd4e] WS-Fed - SP.initSSO: Accessing WS-Fed SP initSSO script
DEBUG [c7388fcd4e] Session: 'wsfed' not valid because we are not authenticated.
Oct 10 19:19:15 simplesamlphp INFO [c7388fcd4e] WS-Fed - SP.initSSO: Accessing WS-Fed SP initSSO script
which repeats...
Upon further evaluation, right after we enter the username and password, the following was captured from the IdP:
wa=wsignin1.0
wresult:
<?xml version="1.0" encoding="UTF-8"?>
<trust:RequestSecurityTokenResponseCollection xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
<trust:RequestSecurityTokenResponse Context="https://hyundai-test.safe-guardproducts.com/">
<trust:Lifetime>
<wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2012-10-10T23:19:13.653Z</wsu:Created>
<wsu:Expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2012-10-11T00:19:13.653Z</wsu:Expires>
</trust:Lifetime>
<wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
<Address>https://oursite.com/</Address>
</EndpointReference>
</wsp:AppliesTo>
<trust:RequestedSecurityToken>
<Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="_a598b962-b0f3-4203-8870-08242c6e95a3" IssueInstant="2012-10-10T23:19:13.669Z" Version="2.0">
<Issuer>Dealer Access Sign-In STS</Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<ds:Reference URI="#_a598b962-b0f3-4203-8870-08242c6e95a3">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<ds:DigestValue>0dr1zPr3...</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>VZf8....</ds:SignatureValue>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>MIICHTC...=</X509Certificate>
</X509Data>
</KeyInfo>
</ds:Signature>
<Subject>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer" />
</Subject>
<Conditions NotBefore="2012-10-10T23:19:13.653Z" NotOnOrAfter="2012-10-11T00:19:13.653Z">
<AudienceRestriction>
<Audience>https://oursite.com</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
<AttributeValue>theUserNameAtIdPSite</AttributeValue>
</Attribute>
<Attribute Name="http://sts.xxx.com/claims/Title">
<AttributeValue>Principal</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
<AttributeValue>Test</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
<AttributeValue>Safe</AttributeValue>
</Attribute>
<Attribute Name="http://sts.hcadealeraccess.com/claims/IsActive">
<AttributeValue>True</AttributeValue>
</Attribute>
<Attribute Name="http://sts.xxx.com/claims/IsApproved">
<AttributeValue>True</AttributeValue>
</Attribute>
<Attribute Name="http://sts.xxx.com/claims/CreationDate">
<AttributeValue>9/26/2012</AttributeValue>
</Attribute>
</AttributeStatement>
</Assertion>
</trust:RequestedSecurityToken>
<trust:RequestedAttachedReference>
<SecurityTokenReference xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:d4p1="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd" d4p1:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0">
<KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID">_a598b962-b0f3-4203-8870</KeyIdentifier>
</SecurityTokenReference>
</trust:RequestedAttachedReference>
<trust:RequestedUnattachedReference>
<SecurityTokenReference xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:d4p1="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd" d4p1:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0">
<KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID">_a598b962-b0f3-4203-8870-08242c6e95a3</KeyIdentifier>
</SecurityTokenReference>
</trust:RequestedUnattachedReference>
<trust:TokenType>urn:oasis:names:tc:SAML:2.0:assertion</trust:TokenType>
<trust:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</trust:RequestType>
<trust:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Bearer</trust:KeyType>
</trust:RequestSecurityTokenResponse>
</trust:RequestSecurityTokenResponseCollection>
After entering the username and password, we received the following from the IdP
wctx= https://oursite.com/
I also notice the RelayState=https://oursite.com
INFO [c7388fcd4e] WS-Fed - SP.initSSO: Accessing WS-Fed SP initSSO script
DEBUG [c7388fcd4e] Session: 'wsfed' not valid because we are not authenticated.
Oct 10 19:19:15 simplesamlphp INFO [c7388fcd4e] WS-Fed - SP.initSSO: Accessing WS-Fed SP initSSO script
which repeats...
Upon further evaluation, right after we enter the username and password, the following was captured from the IdP:
wa=wsignin1.0
wresult:
<?xml version="1.0" encoding="UTF-8"?>
<trust:RequestSecurityTokenResponseCollection xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
<trust:RequestSecurityTokenResponse Context="https://hyundai-test.safe-guardproducts.com/">
<trust:Lifetime>
<wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2012-10-10T23:19:13.653Z</wsu:Created>
<wsu:Expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2012-10-11T00:19:13.653Z</wsu:Expires>
</trust:Lifetime>
<wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
<Address>https://oursite.com/</Address>
</EndpointReference>
</wsp:AppliesTo>
<trust:RequestedSecurityToken>
<Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="_a598b962-b0f3-4203-8870-08242c6e95a3" IssueInstant="2012-10-10T23:19:13.669Z" Version="2.0">
<Issuer>Dealer Access Sign-In STS</Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<ds:Reference URI="#_a598b962-b0f3-4203-8870-08242c6e95a3">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<ds:DigestValue>0dr1zPr3...</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>VZf8....</ds:SignatureValue>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>MIICHTC...=</X509Certificate>
</X509Data>
</KeyInfo>
</ds:Signature>
<Subject>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer" />
</Subject>
<Conditions NotBefore="2012-10-10T23:19:13.653Z" NotOnOrAfter="2012-10-11T00:19:13.653Z">
<AudienceRestriction>
<Audience>https://oursite.com</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
<AttributeValue>theUserNameAtIdPSite</AttributeValue>
</Attribute>
<Attribute Name="http://sts.xxx.com/claims/Title">
<AttributeValue>Principal</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
<AttributeValue>Test</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
<AttributeValue>Safe</AttributeValue>
</Attribute>
<Attribute Name="http://sts.hcadealeraccess.com/claims/IsActive">
<AttributeValue>True</AttributeValue>
</Attribute>
<Attribute Name="http://sts.xxx.com/claims/IsApproved">
<AttributeValue>True</AttributeValue>
</Attribute>
<Attribute Name="http://sts.xxx.com/claims/CreationDate">
<AttributeValue>9/26/2012</AttributeValue>
</Attribute>
</AttributeStatement>
</Assertion>
</trust:RequestedSecurityToken>
<trust:RequestedAttachedReference>
<SecurityTokenReference xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:d4p1="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd" d4p1:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0">
<KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID">_a598b962-b0f3-4203-8870</KeyIdentifier>
</SecurityTokenReference>
</trust:RequestedAttachedReference>
<trust:RequestedUnattachedReference>
<SecurityTokenReference xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:d4p1="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd" d4p1:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0">
<KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID">_a598b962-b0f3-4203-8870-08242c6e95a3</KeyIdentifier>
</SecurityTokenReference>
</trust:RequestedUnattachedReference>
<trust:TokenType>urn:oasis:names:tc:SAML:2.0:assertion</trust:TokenType>
<trust:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</trust:RequestType>
<trust:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Bearer</trust:KeyType>
</trust:RequestSecurityTokenResponse>
</trust:RequestSecurityTokenResponseCollection>
After entering the username and password, we received the following from the IdP
wctx= https://oursite.com/
I also notice the RelayState=https://oursite.com
> Once authenticated, how can we read the claim information?
$session = SimpleSAML_Session::getInstance();
$session->getAttributes();
Understood - thank you.
> Any and all help is greatly appreciated!
I cannot really offer very much help with it -- I am not familiar with
WS-Federation, so I do not know much about how it is supposed to work.
Since ADFS 2.0 supports SAML 2.0 I guess most of the community is
moving to SAML 2.0 as well.
Yes - I asked them about setting us up a SAML2.0 Idp. The said that they are using WIF and it would take too long for them to convert and they did not think they could support two protocols in MS-Windows. I don't know enough about their system or the products to validate their answer.
Thanks again for your help.
Thanks again for your help.
Olav Morken
Oct 11, 2012, 1:51:25 AM10/11/12
to simple...@googlegroups.com
On Wed, Oct 10, 2012 at 18:59:08 -0700, Dimitri Kartsonas wrote:
> > > In authsource.php
> > > 'default-sp' => array(
> > > 'saml:SP',
> > > 'privatekey' => 'Ourrsaprivkey.pem',
> > > 'certificate' => 'OurTest.cer'
> >
> > That is for a SAML service provider. It is not used for WS-Federation.
> >
> > Is authsource.php used at all for a wsfed configuration?
No, as I mentioned, WS-Federation support isn't ported to the new
> > > In authsource.php
> > > 'default-sp' => array(
> > > 'saml:SP',
> > > 'privatekey' => 'Ourrsaprivkey.pem',
> > > 'certificate' => 'OurTest.cer'
> >
> > That is for a SAML service provider. It is not used for WS-Federation.
> >
> > Is authsource.php used at all for a wsfed configuration?
authentication system.
> > Great - it took me some time to understand what you meant. Below is the
> configuration from or wsfed-SP-hosted:
>
> $metadata['https://oursite.com'] = array(
> 'host' => 'oursite.com',
> 'privatekey' => 'ourPrivateKey.pem',
> 'certificate' => 'ourPublicKey.cer',
>
> Two questions:
>
> 1. Are the key settings correct?
SP.
> 2. What additional parameters should be set for wsfed?
> > > Also, what are we missing in the configuration / setup to get
> > authenticated
> > > ?
> >
> > What happens instead of getting authenticated?
> >
> > When we enter the login information at the remote Idp the page disappears
> and redirects back to our site. I traced the exchange using fiddler and
> the session bounces back and forth between our site and the Idp. the
> following is the only information captured in the logfile:
> INFO [c7388fcd4e] WS-Fed - SP.initSSO: Accessing WS-Fed SP initSSO script
> DEBUG [c7388fcd4e] Session: 'wsfed' not valid because we are not
> authenticated.
> Oct 10 19:19:15 simplesamlphp INFO [c7388fcd4e] WS-Fed - SP.initSSO:
> Accessing WS-Fed SP initSSO script
not get an entry with �WS-Fed - SP.AssertionConsumerService: Accessing
WS-Fed SP endpoint AssertionConsumerService� in your log, so it doesn't
look like it is sent to the right URL.
Dimitri Kartsonas
Oct 11, 2012, 10:13:59 PM10/11/12
to simple...@googlegroups.com
Hi Olav,
Thank you for your support, your commitment and support is greatly appreciated by all (I noticed your post to others - thank you).
I understand your statement on the authentication; however, for wsfed where do you set the Ath end point (acs?). I understand there is limited docs and support on wsfed so I am at a loss at where to configure these elements. Perhaps there is documentation from an earlier version that has content on wsfed?
If you suggest we are at an end with wsfed, not because of SSP, but due to our vendor selection, is there another vendor you suggest has support for the wsfed (WIF) implementation?
Regards,
Dimitri
On Tuesday, October 9, 2012 9:28:01 PM UTC-4, Dimitri Kartsonas wrote:
Thank you for your support, your commitment and support is greatly appreciated by all (I noticed your post to others - thank you).
I understand your statement on the authentication; however, for wsfed where do you set the Ath end point (acs?). I understand there is limited docs and support on wsfed so I am at a loss at where to configure these elements. Perhaps there is documentation from an earlier version that has content on wsfed?
If you suggest we are at an end with wsfed, not because of SSP, but due to our vendor selection, is there another vendor you suggest has support for the wsfed (WIF) implementation?
Regards,
Dimitri
On Tuesday, October 9, 2012 9:28:01 PM UTC-4, Dimitri Kartsonas wrote:
Hello,
We are trying to use SSP in our application as a SP and authenticate to a Windows STS IdP.
In authsource.php
'default-sp' => array(
'saml:SP',
'privatekey' => 'Ourrsaprivkey.pem',
'certificate' => 'OurTest.cer'
In wsfed-idp-remote.php
$metadata['remote'] = array(
'prp' => 'https://staging.xxx.com',
'certificate' => 'their-token.cer'
);
We used the code from the www/example-simple/wsfed-example.php as the base code for our test application.
We get redirected to the login page of the Windows STS and entered the login information but were not authenticated.
I noticed the header request had the realm set to urn:federation:oursite.com. (In the STS our URL is 'https://oursite.com)
Is there a way to change the request?
Also, what are we missing in the configuration / setup to get authenticated ?
Once authenticated, how can we read the claim information?
Olav Morken
Oct 12, 2012, 8:40:16 AM10/12/12
to simple...@googlegroups.com
On Thu, Oct 11, 2012 at 19:13:59 -0700, Dimitri Kartsonas wrote:
> Hi Olav,
>
> Thank you for your support, your commitment and support is greatly
> appreciated by all (I noticed your post to others - thank you).
You're welcome!
> Hi Olav,
>
> Thank you for your support, your commitment and support is greatly
> appreciated by all (I noticed your post to others - thank you).
> I understand your statement on the authentication; however, for wsfed where
> do you set the Ath end point (acs?). I understand there is limited docs
> and support on wsfed so I am at a loss at where to configure these
> elements.
I think it is configured on the server you send authentication requests
to, and I think it should be set to something like:
https://yourhost/simplesaml/wsfed/sp/prp.php
> Perhaps there is documentation from an earlier version that has
> content on wsfed?
has always been SAML 2.0. I sort of assume that the reason it was added
to simpleSAMLphp was to allow for bridging between SAML 2.0 and
WS-Federation.
Unfortunately, whoever wrote the WS-Federation support in simpleSAMLphp
did not contribute documentation for it.
> If you suggest we are at an end with wsfed, not because of SSP, but due to
> our vendor selection, is there another vendor you suggest has support for
> the wsfed (WIF) implementation?
recommend anything here.
Reply all
Reply to author
Forward
0 new messages