In the exemple code of MVC, is used the itfoxtec.identity.saml2.testwebapp_Certificate.pfx:
https://github.com/ITfoxtec/ITfoxtec.Identity.Saml2/blob/master/test/TestWebApp/App_Data/itfoxtec.identity.saml2.testwebapp_Certificate.pfx
in this part:
https://github.com/ITfoxtec/ITfoxtec.Identity.Saml2/blob/10cba6a1a8be236046b9caab0651eba9002b55ee/test/TestWebApp/App_Start/IdentityConfig.cs#L29
But I don't understand the why i need this, because already had the certificate of the IdP, and if there is some way that i don't use this.
The IdP certificate is used to sign the authn response (SAML 2.0 token) from the IdP.
The SAML 2.0 standard says that a rp (relying party) like the TestWebApp need to sign logout request. the TestWebApp sample application sign the request with the itfoxtec.identity.saml2.testwebapp_Certificate.pfx certificate.
It is not required for a rp to sign login request and therefore the itfoxtec.identity.saml2.testwebapp_Certificate.pfx certificate is not required if the rp only do login and not logout.
Related
I am setting up an IDP initiated SAML authentication flow
One of our clients will send an SAML assertion request to us by clicking a link within their internal system to access our application - so we act as the service Provider (we use Identity Server from Duende for Authentication)
We are looking at using ITfoxtec.Identity.Saml2.MvcCore library
AS we are going with an IDP initiated SAML flow, I wanted to check to know if
As an SP (Service Provider) do we only need to have an ACS end point for the incoming SAML Assertion. On receiving the Assertion we can process it to get the Claims we need and if it meets our requirements we can give the access to our application.
Do we need to send back any notification to the IDP that sent us the Assertion ?
Once verified after receiving the Assertion, do we set the access token in our Identity Server or do we get a token in, the assertion. We need periodically need to check if the user associated with the incoming Assertion is still authenticated in the IDP. Hence I was wondering if the IDP would issue a token with an expiration date/time, if not then would we have to initiate a new SP initiated SAML flow to check if the user is still authenticated with the Client IDP ?
DO we as an SP need to issue our own Access Token ?
For Logout, we only want to log the user out of our system (So remove our token if we issue one, we do not want to log out the user from their IDP?
Do we need to simulate login in our Identity Provider or will that happen automatically when we add the SAML2 to our Authentication method in our startup.cs
Do we use the ITfoxtec.Identity.Saml2.MvcCore library as we are using Duende IdentityServer in a .netCore 5.0 setup
is this possible with ITfoxtec library ?
services.AddAuthentication()
.AddSaml2(options =>
{
var spOptions = new SPOptions
{
EntityId = new EntityId("https://localhost:44373/Saml2"),
ReturnUrl = new Uri("https://localhost:44373"),
MinIncomingSigningAlgorithm = "http://www.w3.org/2000/09/xmldsig#rsa-sha1",
};
options.SPOptions = spOptions;
options.IdentityProviders.Add(new IdentityProvider(new EntityId("https://www.example.com/SSO/SAML/App"), options.SPOptions)
{
AllowUnsolicitedAuthnResponse = false,
MetadataLocation = "https://www.example.com/SSO/SAMLMetadata/App",
LoadMetadata = true,
});
});
Yes and you only need the ACS endpoint. You can also do logout if it is supported by the IdP.
No
You resave a SAML 2.0 token in the Assertion which has a lifetime. To check user state you either need the IdP to start a new IdP initiated login or you can start a SP initiated login, if supported by the IdP.
No. That do not has anything to do with the SAML 2.0 integration.
In IdP initiated scenarie the SP usually do not request the IdP to logout.
You need to simulate IdP initiated login, you can use this code sample.
You can integrate ITfoxtec Identity Saml2 into Duende IdentityServer but I do not have a sample on that.
I have a basic question on setting up trust between a SP and IDP.
Usually a two way trust is required when we setup an IDP with SP by uploading certificates on either side.
Is signing certificate from SP mandatory to be configured in the IDP side ?
Best Regards,
Saurav
You only need a signing keypair on the SP side if you send the subject in the AuthnRequest, and your IdP utilizes the information when provided. If your SP isn't sending the subject attribute or your IdP won't consume it, you don't need it.
The defined SAML 2.0 specifications doesn't mandate that the request is signed.
4.1.3.3 <AuthnRequest> Is Issued by Service Provider to Identity Provider
...The <AuthnRequest> message MAY be signed, if authentication of the request issuer is required.
You can check with your Identity Provider documentation, but for example, Microsoft Azure AD does not validate signed requests, and there's no way to upload a request signing certificate.
I have setup an Application that's is using OKTA as IDP. The app is SAML Based.This part is working fine.
But I am unable to log out. For this we have
1. Enabled Single Logout
2. Set the Single Log out URL (I received this from Metadata of IDP under header Identity Provider Single Logout URL)
3.Sp Issues (I received this from Metadata of IDP under header Identity Provider Issuer )
4. Signature Certificate (This is the certificate of IDP)
Now when I call the Logout URL I am receiving 403. On checking the Logs of OKTA I see the (User Single Sign out from App Failure:- Malformed Request)
Can any one please help me how to fix it.
I am assuming that I just need to call the logout URL and the session will kill off. Is my understanding correct?
Reviving a very old thread, check that you have a ?ReturnTo=<path> at the end of the logout URL.
Okta requires strictly post binding requests for logout. Please make sure you are making POST requests for logout and you are using correct entity Id in request.
I think the setting values below need to be set for sp side.
Set the Single Log out URL
Sp Issues
Signature Certificate
It is not on idp side.
In Azure AD, when we make a call such as AuthenticationContext.AcquireTokenAsync(resource, new ClientAssertionCertificate(_clientId, _cert)) it is not clear what exactly happens.
What part of the certificate gets exchanged if any?
Is there a challenge/response taking place?
Is the private key needed on the client as a part of this?
There are two ways you could go about finding the answer to you questions. One would be to look at the Microsoft Active Directory Authentication Library (ADAL) for .NET source code on GitHub, since this is open-source. The other (which we'll do here) is to looking at the network request that AcquireTokenAsync(String, ClientAssertion) generates, and work backwards from there.
Using Fiddler (or any other traffic analyzer), we can see something like the following (formatted for readability):
POST https://login.microsoftonline.com/{tenant-id}/oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
&resource=https%3A%2F%2Fgraph.windows.net
&client_id={app-id}
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1N...VE8wHSf-HZvGQ
Breaking it down:
grant_type=client_credentials tells us this is a token request using the OAuth 2.0 Client Credentials Grant flow.
resource=https%3A%2F%2Fgraph.windows.net gives the URI of the resource the client is requesting an access token for. In this case, it's for the Azure AD Graph API.
client_id={app-id} is the client identifier. In Azure AD, this is the app ID of the application that was registered.
The presence of client_assertion_type and client_assertion are indicative that the client is using an assertion to authenticate:
client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer says that client assertion being used is a signed JSON Web Token (JWT).
client_assertion=eyJhbGciOiJSUzI1N...VE8wHSf-HZvGQ is the aforementioned signed JWT token. The authorization server (e.g. Azure AD) will validate the contents, and check that the token was indeed signed by the certificate authorized for the client in question.
So, what ADAL does is:
Construct a token with a set of claims about the client (your app)
Use your certificate's private key to generate a cryptographic signature of those claims
Bundle that up into a signed JWT
Make an appropriately formed token request to the authority
During AcquireTokenAsync, only the certificate's thumbprint is provided (it's included in the JWT header to help the authorization server look up the corresponding public key). The JWT's signature is what proves that the client is in possession of the private key. However, before AcquireTokenAsync(String, ClientAssertion) can be used successfully, the client owner (i.e. you) needs to have provided Azure AD with the certificate's public key.
There is no challenge/response taking place here. The token is obtained in a single request, initiated by the client.
For a lot more detail, you can review the standards that this all implements:
RFC 6749: The OAuth 2.0 Authorization Framework
RFC 7521: Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants
RFC 7523: JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants
RFC 7519: JSON Web Token (JWT)
(Note that ADAL has a cache. Everything I described above will take place only if ADAL does not find a valid access token in the token cache. You can use AuthenticationContext.TokenCache.Clear() to clear the cache for experimentation.)
We have a successful implementation of SSO with Okta as the IdP and an external PHP site as a SP. We are currently utilizing the Okta Sign On Widget which sends our PHP SP a SAML2 Token.
Question is, can we now change from the widget to the API and still get the SAML 2 token on successful login via the API?
So, Since posting this I figured out that - 'yes you can'. I don't know if this is the cleanest/best way but it works and here is how to do it in case anyone else gets stuck looking into this issue...
Already having SAML2 communication working between Okta as IdP and
PHP site as SP.
Create an API access token in Okta.
Use the access token to post a request for a one-time use token from
the API for a specific user you want to login as:
http://developer.okta.com/docs/api/resources/sessions.html
Redirect the user with the retrieved one-time session token to your
App's embed link with the one-time session token:
http://developer.okta.com/docs/examples/session_cookie.html#retrieving-a-session-cookie-by-visiting-an-application-embed-link
This will log the user into Okta to get a proper session we can then
use to send to our PHP end-point to get the SAML2 token we want but
while utilizing the full customization benefits of the API.