I am interfacing with an IDP and have a basic AuthNRequest created as follows:
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="IDTest1"
Version="2.0"
IssueInstant="2013-03-04T09:21:59"
AssertionConsumerServiceIndex="0"
AttributeConsumingServiceIndex="0">
<saml:Issuer>https://myapp.com/saml2/sp</saml:Issuer>
<samlp:NameIDPolicy
AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</samlp:AuthnRequest>
IDP wants me send the request as signed. My questions are:
How do I set digest value?
How do I set Signature value?
For x509 certificate, I set the public key of my app. Correct?
What is the data that is used to compute any of the values? Is it my original auth request without Signature element?
Just to note that a lot of this is covered in the documentation:
SAML metadata.
To have the request signed you need to add something like this (normally found in the sp.xml):
<SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="false"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
The signing key would look something like:
<KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>
MIIDWTC...CAkGgAwIBAgIEe+a+/uaSZCp5g2z+hRWRV+DyfQc9nO
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
where the MII... is the public key.
As per #Stefan, it's much easier to use a library.
SAML Authentication Request is an XML document. You can sign SAML Authentication Request just like signing any other XML document. There are, however, some restrictions:
The signature must be enveloped signature.
Before it is digested, the SAML Authentication Request must not be transformed by method other than enveloped signature transform and exclusive canonicalization transform.
The Signature element must contain only one Reference element.
The URI of the only Reference element must contain the value of the ID attribute of the signed SAML Authentication Request.
Before it is signed, the SignedInfo element must be canonicalize using exclusive canonicalization method.
You can read more detail the SAML Assertions and Protocols Specification (http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf) in Section 5.
Your question is inadequate!
The AuthRequest you're sending seems to be REDIRECT request where you will not see Digest, Signature and Certificate since all these details will be in URL as a parameter.
Try using POST SSO request, where you will see Digest, Signature and Certificate in SAML request.
Some of the points:
Common
Both IdP and SP should share their Metadata, which will have their basic configuration like id, signing algorithm, hashing method, public key etc.
So, based on the contract between IdP you should hash and sign your request in your preferred programming language.
SP:
You should encrypt using your public key.
You should sign using your private key.
You should encode your request using Base64.
IdP:
They will identity using the public key in the request.
They will respond back with encrypted and signed XML.
You should decrypt and unsign the response.
Quick Links
Official Doc about SAML 2.0
SAML Online Tool by OneLogin
If your into constructing your own requests without any bigger frameworks around I can recommend OpenSAML. Its a library to help with the construction of SAML messages.
In my book, A Guide to OpenSAML, this and more is explained in detail.
EDIT I have released a new edition of the book, covering OpenSAML V3
Here is an example I wrote on signing SAML messages
And one on how to dispatch AuthnRequests.
Well things concerning security are never easy...
you sholud definetly check documentation Linked by #nzpcmad, as well as
SAML2 profiles (look for WB SSO - Web Browser Single Sign On).
For Java OpenSaml is indeed one of easiest solutions.
A pitfall seems to be that with HTTP-Redirect Binding the Signature is transported by additional URL-Parameters and not part of the SAMLRequest value, e.g. https://my-idp.com/login?SAMLRequest=nVNN...%3D&SigAlg=http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmldsig-more%23rsa-sha256&Signature=QZ64...%3D%3D
Related
I have configured IdentityServer 3 to use external IdentityProvider which is pointing to AAD.
As of now, when I send a request to IdentityServer, I am properly redirected to the AAD for login, however, the 'state' parameter that I am sending to IdentityServer is overridden, and the value of OpenIdConnect.AuthenticationProperties is encrypted and sent to the AAD as the state in the query string.
For eg:
https://localhost:44333/idpaad/connect/authorize?client_id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx&redirect_uri=https://localhost:44394/&response_mode=query&response_type=code&scope=openid%20email&state=9b0e82c3-e623-42f1-bede-493243c103e7
Here,
https://localhost:44333/idpaad/connect/authorize -> IdentityServer endpoint
state=9b0e82c3-e623-42f1-bede-493243c103e7 -> client generated GUID sent as querystring.
when I see in the "RedirectToIdentityProvider" middleware in the StartUp.cs of IdentityServer OpenIdConnectAuthenticationNotifications, the value of state is updated to
OpenIdConnect.AuthenticationProperties=(protected values) instead of the GUID and the same is also returned as a query string back to the Redirect URI.
enter image description here
Is there a way to send the original state and not override it by IdentityServer3?
While using wsFederation, I am not getting this issue and the same is forwarded directly to the IdP.
Any help is deeply appreciated.
Most of the time it's advisable for an Azure Active Directory integrated application to maintain an application state when sending request to Azure AD for login. And the recommended way to achieve this is to use the ‘state’ parameter as defined in the OpenID Connect standards.
If you check this document form OpenID, you will find that primary reason for using the state parameter is to mitigate CSRF attacks.
RECOMMENDED. Opaque value used to maintain state between the request and the callback. Typically, Cross-Site Request Forgery (CSRF, XSRF) mitigation is done by cryptographically binding the value of this parameter with a browser cookie.
The ‘state’ parameter is used for both preventing cross-site request forgery attacks and to maintain user’s state before authentication request occurs.
In an ASP.NET or ASP.NET CORE web application using OpenID Connect OWIN middleware, the ‘state’ parameter is maintained automatically by the middleware when sending out an authentication request, this is the only reason you are seeing the state parameter getting overridden in your case.
But if you want you can add custom data in your state parameter. Use the following code in OpenIdConnectNotifications’s RedirectToIdentityProvider event to inject custom data into the ‘state’ parameter.
var stateQueryString = notification.ProtocolMessage.State.Split('=');
var protectedState = stateQueryString[1];
var state = notification.Options.StateDataFormat.Unprotect(protectedState);
state.Dictionary.Add("MyData","123");
notification.ProtocolMessage.State = stateQueryString[0] + "=" + notification.Options.StateDataFormat.Protect(state);
Check this document and Microsoft identity platform and OpenID Connect protocol for detailed information.
I need to implement a SAML assertion flow using Spring OAuth2 Authorization Server. I'm struggling with how to tie these two projects up.
I've tried importing the SAML securityContext into my OAuth project as well, however it seems that the SAML flow will always take precedence. Is there a way to do this where it would look at the grant_type to determine if it should use the saml flow.
Also, when it does process the saml assertion, would that tie into the ResourceOwnerPasswordTokenGranter, or would I have to register a custom token granter with something like this?
With OAuth2, we have a way of registering different TokenGranters through something like this:
List<TokenGranter> tokenGranters = new ArrayList<TokenGranter>();
tokenGranters.add( endpoints.getTokenGranter());
tokenGranters.add(new SamlTokenGranter(authenticationManager,tks,cds,endpoints.getOAuth2RequestFactory()));
CompositeTokenGranter ctg = new CompositeTokenGranter(tokenGranters);
endpoints.tokenGranter(ctg);
thanks ahead of time for any help you can provide
You might need to register a custom TokenGranter. The CompositeTokenGranter (the default) can handle multiple grant types by doing what you suggest (comparing the incoming requested grant_type to the one supported by each granter). If you are using Spring SAML as a service provider to check the assertion, then I guess you also need to set that up as a separate security filter on the /token endpoint (with a very specific request matcher so it only intercepts SAML grants).
So I'm very new with HMAC authentication and I really don't know what I'm doing nor reading atm.
I've been trying to understand the following articles / links / discussions properly:
How to implement HMAC Authentication in a RESTful WCF API
http://blogs.microsoft.co.il/blogs/itai/archive/2009/02/22/how-to-implement-hmac-authentication-on-a-restful-wcf-service.aspx
http://buchananweb.co.uk/security01.aspx
With that said I have a few questions:
Understanding the first link, if for example I have a loginAuthentication service created in .net and will be accessed from an iPhone app do I pass an unencrypted username (message) for this and should return just a true / false or should it return an encrypted string in which I will be using later on for other transactions (Delete, Insert services, etc)?
[ServiceContract]
public partial class LoginService
{
[OperationContract]
bool Authenticate(string username) {
// stuffs
}
}
With that said, after I verified the user, and this is where I get lost. Is it better that I save something in the database 'with a timestamp' (someone told me about this and I read some discussions about this too)? Or do I just return it with the encrypted message (dependent on the first question) so that everytime a request is made the timestamp is already attached?
a. And what do I do with that timestamp?
b. Is it going to be used once the message is sent again for another transaction?
Keys and secret message. The way I understood it is that the key will be the password of the user. So if the user sends his username I can open the message using the password of that user? This makes sense if the user already has a session and is just requesting to get data or requesting for a delete, insert, etc. Should it still be the same way if it's just authenticating the username and password of the user?
Thank you for your time!
The first thing I would like to mention is that the WCF Web Api was a beta project which is no longer being developed. It was replaced by ASP.NET Web API which is an awesome framework for developing RESTful services.
If you want to get a good idea how a RESTful service and authentication works the Netflix API would be a great place to start. They have a lot of documentation regarding the security portion and this helped me understand HMAC a lot more.
HMAC creates a hash using a secret key. The client and server both maintain a copy of the secret key so that they can generate matching hashes. This allows you to 'sign' a request which serves as both authentication (you know the person sending it is who they say they are), and message integrity (knowing the message they sent is the original message and has not been tampered with).
A signature is created by combining
1. Timestamp (unix epoc is the easiest to send in urls)
2. Nonce (a random number that can never be used twice to protect against someone re-using it)
3. Message (for a GET request this would be the URL, a POST would be the whole body)
4. Signature (the three previous items combined and hashed using the secret key)
Each of the above can be sent in the query string of the request, then the server can use the first 3 and their copy of the secret key to recreate the signature. If the signatures match then all is good.
In a RESTful API that is over plain HTTP (not using HTTPS over an ssl), I would sign every request sent because again this authenticates and provides message integrity. Otherwise if you just send an authentication token you know the user is authenticated but how do you know the message was not tampered with if you do not have a Message Digest (the HMAC hash) to compare with?
An easy way to implement the server-side checking of the signature is to override OnAuthorization for System.Web.Http.AuthorizeAttribute (Make sure not to use Mvc autorize attribute). Have it rebuild the signature just as you did on the client side using their secret key, and if it does not match you can return a 401. Then you can decorate all controllers that require authentication with your new authorize attribute.
Hopefully this helps clear up some of your confusion and does not muddy the water even further. I can provide some more concrete examples later if you need.
References:
Netflix Api Docs: http://developer.netflix.com/docs/Security#0_18325 (go down to the part about creating signatures, they also have a link which shows a full .NET example for creating the HMAC signature)
.NET class for creating HMAC signatures http://oauth.googlecode.com/svn/code/csharp/OAuthBase.cs
Netflix API Wrapper I wrote: https://bitbucket.org/despertar1318/netflix-api/overview
ASP.NET Web API: http://www.asp.net/web-api
Looking at your questions in turn
...do I pass an unencrypted username (message) for this and should return just a true / false or should it return an encrypted string in which I will be using later on for other transactions (Delete, Insert services, etc)?
If you just returned a boolean, you'd have no way to then match the authentication request to subsequent requests. You'll need to return some sort of authentication indicator, on a classic website this would be the session cookie, in your instance you want to pass a value that will act as shared key.
Is it better that I save something in the database 'with a timestamp'? Or do I just return it with the encrypted message so that everytime a request is made the timestamp is already attached?
Back to the session analogy, you want to store the key from question one somewhere (the database?) with a timestamp that indicates the life of the session/validity of the key. If it's forever then I wouldn't bother with the timestamp, if it's anything else you'll need something to say when it expires.
The way I understood it is that the key will be the password of the user. So if the user sends his username I can open the message using the password of that user? This makes sense if the user already has a session and is just requesting to get data or requesting for a delete, insert, etc. Should it still be the same way if it's just authenticating the username and password of the user?
This is where the HMACing happens. You have your shared secret, you have a message, this is how I usually combine it all together.
Use all of the message as the body of data to be hashed (that way you can be sure that someone's not just copied the hash and part of the message). Hash the body of the message using the key we shared in step one. You could salt this if wanted, I'd use the username.
Finally make sure the message contains a timestamp (UTC preferably), this way you can help prevent replaying the message later. The service that's responding to the message can compare the timestamp to what it thinks the time is. If it falls outside given bounds, fail the message. Because the timestamp will be part of the HMAC, someone can't just update the date and replay the message, the hashes won't match as soon as the message is tampered with.
I'm trying to write an ASP.NET application that uses the Google Calendar Service. To do so, I'm using the example shown here.
This is a TasksService application, but the methods should be pretty much the same.
It seems though, that this application uses an older version of DotNetOpenAuth, in which the ClientBase interface had a ClientSecret property. In the new version they removed this propery.
Where did this property go?
It is mandatory for the authorization process
The ClientSecret property was replaced with the ClientCredentialApplicator property (and constructor parameter). This gives you the freedom to express not only the secret, but how it should be communicated (via form POST parameter or HTTP Authorization header).
I am new to web services. The last time I dealt with SOAP was when I created a bunch of wrapper classes that sent requests and received responses back per some response objects/classes I had created. So I had an object to send certain API requests and likewise a set of objects to hold the response back as an object so I could utilize that 3rd party API.
Then someone came to me and said why not just use the wsdl and a web service. Ok, so today I went and created a "Service Reference". I see that this is what's called a "Proxy Class". You just instantiate an instance of this and then walla you have access to all the methods from the wsdl.
But this leaves me with auth questions. Back when I created my own classes manually, I had a class which exposed properties that I would set then access for things like signature, username, password that got sent along with the Http request that were required by whatever 3rd party API I was using to make API calls.
But then with using a Service Reference, how then would I pass this information just like I had done in my custom classes? For instance I'm going to be working with the PayPal API. It requires you to send a signature and a few other pieces of information like username and password.
// Determins if API call needs to use a session based URI
string requestURI = UseAuthURI == true ? _requestURIAuthBased + aSessionID : _requestURI;
byte[] data = XmlUtil.DocumentToBytes(doc);
// Create the atual Request instance
HttpWebRequest request = CreateWebRequest(requestURI, data.Length);
So how do I pass username, password, signature, etc. when using web service references for each method call? Is it as simple as specifying it as a param to the method or do you use the .Credentials and .URL methods of your proxy class object? It seems to me Credentials means windows credentials but I could be wrong. Is it limited to that or can you use that to specify those required header values that PayPal expects with each method call/API request?
Using Web Service or Web Service Reference