Greeting guys. I just downloaded a trial version and was reading the guide for a while.
I am new to SAML authentication so I have some newbie questions.
My university has an identity server. I have installed a service provider on one my of windows server, then after some configuration about IIS my websites hosted on this server can redirect users to be authenticated on the identity server and log themselves in.
As far as I know, the ISAPI plugin provided by Shibboleth intercept users requests to paths that I set up in shibbleth2.xml file. What I don’t know is which part ComponentSpace SAML plugin can do in my environment? If I adopt ComponentSpace, do I need to install the Shibboleth’s service provider on my web server?
I have a sp-cert.pem and sp-key.pem under \opt\shibboleth-sp\etc\shibboleth folder. Should I use them as the value of LocalCertificateFile?
Thanks.
You can use our component to enable your application to act as the service provider with Shibboleth or any other identity provider.
The Shibboleth service provider or ISAPI plug-in is not required if you use our component.
The certificate file formats we support are those supported by the .NET framework’s X509Certificate2 class.
Your service provider certificate file should be a PFX.
You can use openssl to create a PFX file from a PEM file.
The Shibboleth service provider or ISAPI plug-in is not required if you use our component.
The certificate file formats we support are those supported by the .NET framework's X509Certificate2 class.
Your service provider certificate file should be a PFX.
You can use openssl to create a PFX file from a PEM file.
Thanks for your reply.
I ran example project ShibbolethSP which is written in ASP.NET WebForm. I have changed the urls so that the SSO request can go to my identity provider.
The problem, for now, is when I was redirected to my identity server's login page, I always get error messages like "the application you have accessed is not registered for use with this service.".
I know when I set up website on my production service provider server, I need to set values in shibboleth2.xml like follows:
[quote]
<Path
name="AAA/Account/Login"
applicationId="AAA"
authType="shibboleth" requireSession="true"
exportAssertion="false">
urn:mace:BB.edu:gds:entitlement:QQQ
<ApplicationOverride id="AAA"
entityID="http://AA.BB.edu/XX/AAA/shibboleth-sp"
homeURL="https://AA.BB.edu/XX/AAA/"
REMOTE_USER="ShibXXXID" >
https://AA.BB.edu/XX/AAA/Account/Login/Shibboleth.sso"
handlerSSL="true"
cookieProps="https"
checkAddress="false"
lifetime="7200" timeout="3600" />
[/quote]
I think I should set these values when I construct the SSO request. But I don't know what should I do with ComponentSpace. I have read the guide and tried to a day but no luck till now.
Thanks.
I recommend using the ExampleServiceProvider project that’s described in section 10.8 of our Developer Guide PDF. Ignore the sections about the ExampleIdentityProvider.
The ExampleServiceProvider supports SSO with Shibboleth and uses the SAML high-level API and saml.config.
The ShibbolethSP uses the low-level API which is not as easy to follow.
In our testing we used https://www.testshib.org/ and didn’t have to update shibboleth2.xml so I’m not sure exactly what’s required in this file.
Some of it is non-SAML configuration.
Presumably the entityID is the SAML entity ID of your service provider.
This must match the issuer field in the SAML authn request sent by the service provider.
You can update the code in ShibbolethSP or update shibboleth2.xml to ensure these match.
If using the ExampleServiceProvider, it’s the Name field in saml.config that must match with the entityID in shibboleth2.xml.
The ExampleServiceProvider supports SSO with Shibboleth and uses the SAML high-level API and saml.config.
The ShibbolethSP uses the low-level API which is not as easy to follow.
In our testing we used https://www.testshib.org/ and didn't have to update shibboleth2.xml so I'm not sure exactly what's required in this file.
Some of it is non-SAML configuration.
Presumably the entityID is the SAML entity ID of your service provider.
This must match the issuer field in the SAML authn request sent by the service provider.
You can update the code in ShibbolethSP or update shibboleth2.xml to ensure these match.
If using the ExampleServiceProvider, it's the Name field in saml.config that must match with the entityID in shibboleth2.xml.
After passing entityID to authRequest's issuer, my identity provider recognizes my request now. That's awesome.
But another problem come up with me. After user login at identity provider's login page successfully, they will be redirected to a URL on the service provider, say "https://AA.BB.edu/CC/DD/Shibboleth.sso/SAML2/POST". Which code should I change to specify a callback url?
For High-Level API, I'd like to use it. But the problem is I don't know set values like entity when I use High-Level API. For Shibboleth's low-level API, I know I should change something when I construct an AuthRequest object, but how can I do same thing with high-level api? I have looked into the guide and the .chm doc under installation folder, but still confused.
After login at Shibboleth it will send a SAML response to your service provider’s assertion consumer service.
In the ShibbolethSP, this is the SAML/AssertionConsumerService.aspx page.
Similarly, the ExampleServiceProvider has a SAML/AssertionConsumerService.aspx page.
There should be somewhere in the Shibboleth configuration where you specify this URL.
The entity ID is, as I mentioned, equivalent to the Name in saml.config if you’re using the high-level API.
In the ShibbolethSP, this is the SAML/AssertionConsumerService.aspx page.
Similarly, the ExampleServiceProvider has a SAML/AssertionConsumerService.aspx page.
There should be somewhere in the Shibboleth configuration where you specify this URL.
The entity ID is, as I mentioned, equivalent to the Name in saml.config if you're using the high-level API.
Thanks for your patience.
As you said, I changed 's Name property in saml.config (using high-level API). But the error is thrown when I was redirected to identity provider's login page.
After some examination, I found the URL that high-level API generated missed "SigAlg" and "Signature" querystring parameters while low-level API has these. I assume these querystring parameters are related to encryption. My saml config as follows:
[quote]
<?xml version="1.0"?>
https://AA.BB.edu/ZZ/QQ/shibboleth-sp"
Description="Shibboleth"
LocalCertificateFile="Certificates\sp.pfx"
LocalCertificatePassword="PASSWORD"
AssertionConsumerServiceUrl="~/Account/Login" />
https://shibboleth.BB.edu/shibboleth-idp"
SignAuthnRequest="true"
SingleLogoutServiceBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
PartnerCertificateFile="Certificates/BB.cer"
SingleSignOnServiceUrl="https://shibboleth.BB.edu/idp/profile/SAML2/POST/SSO" />
[/quote]
There is one more thing I concern is that when I use low-level API, I change the signing algorithm from SHA-256 to SHA-1, but I don't know how to do it the same when I use high-level API.
If SignAuthnRequest is true, which it is in your configuration, the authn request will be signed.
If using the default binding, HTTP-Redirect, you should see the SigAlg and Signature query string parameters.
The default is SHA-256 but you can specify SHA-1 using the SignatureMethod.
https://www.componentspace.com/Forums/5316/SHA1-vs-SHA256-XML-signatures
For example:
<PartnerIdentityProvider
Name=“<a href=“https://shibboleth.BB.edu/shibboleth-idp””>https://shibboleth.BB.edu/shibboleth-idp"
SignatureMethod=“<a href=“http://www.w3.org/2000/09/xmldsig#rsa-sha1"”>http://www.w3.org/2000/09/xmldsig#rsa-sha1”
If you’re not seeing this, please enable SAML trace and send the generated log as an email attachment to support@componentspace.com mentioning this forum post.
If using the default binding, HTTP-Redirect, you should see the SigAlg and Signature query string parameters.
The default is SHA-256 but you can specify SHA-1 using the SignatureMethod.
https://www.componentspace.com/Forums/5316/SHA1-vs-SHA256-XML-signatures
For example:
<PartnerIdentityProvider
Name="https://shibboleth.BB.edu/shibboleth-idp"
SignatureMethod="http://www.w3.org/2000/09/xmldsig#rsa-sha1"
If you're not seeing this, please enable SAML trace and send the generated log as an email attachment to support@componentspace.com mentioning this forum post.
Got it.
I have added SignatureMethod to 's SignatureMethod. Then change default binding to HTTP-POST.
The weird part is I use the same binding for high-level and low-level APIs, both of them are HTTP-POST now. However, low-level API works fine while high-level API's call to identity server always get a http 400 bad request error when I look the log printed in Chrome's element inspect window.
I have compared two requests (one from high-level API and one from low-level API), they share same HTTP request headers. In the form data, I saw two keys, first one is SAMLRequest, the second one is relayState. Because the form values are encrypted, I can't compare their values by hand. But my assumption is I missed/misconfig some values/ settings in saml.config.
My SSO Initiate code:
public ActionResult SingleSignOn()
{
// To login at the service provider, initiate single sign-on to the identity provider (SP-initiated SSO).
string partnerIdP = WebConfigurationManager.AppSettings[HomeController.AppSettings.PartnerIdP];
string spResourceURL = "https://AA.BB.edu/QQ/";
string relayState = RelayStateCache.Add(new RelayState(spResourceURL, null));
SAMLServiceProvider.InitiateSSO(Response, relayState, partnerIdP);
return new EmptyResult();
}
The saml.config content:
<?xml version="1.0"?>
https://AA.BB.edu/QQ/shibboleth-sp"
Description="Shibboleth"
LocalCertificateFile="Certificates\sp.pfx"
LocalCertificatePassword="Password"
AssertionConsumerServiceUrl="https://AA.BB.edu/QQ/Account/Login" />
https://shibboleth.BB.edu/shibboleth-idp"
SignAuthnRequest="true"
SignatureMethod="http://www.w3.org/2000/09/xmldsig#rsa-sha1"
PartnerCertificateFile="Certificates/sp.cer"
SingleSignOnServiceBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
NameIDFormat="urn:mace:shibboleth:1.0:nameIdentifier"
SingleSignOnServiceUrl="https://shibboleth.BB.edu/idp/profile/SAML2/POST/SSO" />
Do you have any idea or suggestion that I can dig it deeper?
Your could capture two separate log files - one with the working low-level and one with the non-working high-level API.
The log includes the SAML authn request XML before it’s encoded.
You could compare the two.
You’re welcome to send the two logs to us via email if you don’t see anything obvious.