Kindly let us know, what are all the connection method available in SAML2.0 and which one used by default. Also, please let us know, where we can find that information.
If you are talking about SAML from a browser it's just https.
It's just POSTS and GETS.
The specification is on OASIS.
Related
I have been reading a book about SAML 2.0 lately. There was a point in regards to the "typical use and usefulness of SAML metadata" stating the following:
The SP wants to authenticate a user. It looks at the metadata and finds the URL at the IdP where users should be sent. It uses its private key to sign the authentication request and sends it to the URL at the IdP.
The line I am interested the most (and the one I do not well understand yet...) is:
It uses its private key to sign the authentication request and sends it to the URL at the IdP.
My question is - where exactly in any of the existing standard/RFC/alike document may I find info on these exact points mentioned in the SAML book - signing, calling?
For example, it is not clear for me if that's the call signed by a standard HTTPS process or is it SAML-specific-signing + HTTPS, what type of algorithm is in use at signing, what kind of call should happen (GET, POST, other), what kind of parameters (if that's important at all) should be sent with the call... and alike questions related to signing and sending arise. I expect a document of some kind to get into more details and explain signing and calling procedures. Not much success on finding precise pages in right documents yet. Seems like RFC 2818 may be a good direction, or one of many SAML 2.0 specifications, or else.
Pointing to (the part of) the right document containing the info on the signing and the calling would be appreciated. Elaborating a bit on the given quote I do not understand would also benefit a lot.
You have a lot of questions - Not surprising as SAML is a large topic. And there are a lot of documents. Take a look at the following link as it would walk someone through integrating perl's Net::SAML2 into a web application and walks through the steps.
https://github.com/perl-net-saml2/perl-Net-SAML2/blob/master/TUTORIAL.md
However it does gloss over some things. Early on it says:
The IdP object contains the Identity Providers settings that were parse from the metadata and are then used for the rest of the calls.
In that you see a
'sso_urls' => {
'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST' => 'https://accounts.google.com/o/saml2/idp?idpid=CXXXXXXXX',
'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect' => 'https://accounts.google.com/o/saml2/idp?idpid=CXXXXXXXX'
},
If you ignore the 40+ page doc on metadata https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf These are the two methods the IdP used for the sign on and specified a HTTP-Redirect and a POST method. IN this case the URL's match but they do not need to.
The creation of the HTTP-Redirect for the AuthnRequest alone is a minor feat. https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf. Page 15 3.4 HTTP Redirect Binding describes the method. It is essentially taking the XML AuthnRequest and using the DEFLATE compression method (see
[RFC1951]) The result is Base64 encoded and assigned to SAMLResponse and has the RelayState (if any) and SigAlg appended as GET request parameters. The result is Signed using a accepted algorithim like rsa-sha256 and the base 64 signature is added to the query parameter that are normally URL encoded to be requested via the browser. See https://github.com/perl-net-saml2/perl-Net-SAML2/blob/064f718178c3fa6edfe0b262fe4b5e4c8705411b/lib/Net/SAML2/Binding/Redirect.pm#L117
So, learning it is walking through each part of the process. There are multiple documents that address certain parts. It relies heavily on other existing standards and RFCs. For instance the POST request and much of the communication uses xml-dsig unlike the HTTP-Request (space limitation in URLs). That is a beast in itself.
I support Net::SAML2 and can answer specific questions. Despite its size SAML is a fairly simple (yet extraordinarily complex) protocol. I quite like it
I think it is my book you are referring to =) SAML 2.0: Designing secure identity federation
SAML is not straight forward and simple so you are not alone in having difficulty in grasping it. You have a lot of questions but I will try and answer them as best I can.
How SAML messages are sent is called bindings. For example POST or Redirect. These are defined in the bindings spec and discussed in chapter 6 of the book.
SAML traffic should always use HTTPS, but in addition the XML should be singing to protect the message from tampering in the browser as HTTPS does not protect against this. The difference between these are discussed under Transport and message protection in chapter 12 of the book.
What messages are sent how they are sent and and how they need to be protected in SSO is defined in the Web Browser SSO Profile in the profiles spec and discussed in chapter 8 of the book.
How signatures are processed and formats are defined in chapter 5.4 of the SAML core spec
I hope this helps to guide you right.
In ITfoxtec SAML 2.0 implementation, Saml2PostBinding object has SetRelayStateQuery() and GetRelayStateQuery() methods to set and get data from dictionary.
Sometimes, GetRelayStateQuery() returns Empty dictionary even though I have set values using SetRelayStateQuery(). I am not able to reproduce this while testing but it is happening for many clients on production. In which scenarios may this happen?
The SetRelayStateQuery() should be used in the RP (relying party) and then the GetRelayStateQuery() in the IdP (identity provider). The methods should not be used in the samme application.
You can trace the error by looking at the SAML send between the parties.
App Engine python runtime, latest SDK ... using urlfetch to request over https. No matter what value I use for verify_certificate (True, False, None), I get back the same response from an internal site with a fake certificate,
Invalid and/or missing SSL certificate for URL:
The documentation suggests that setting verify_certificate to False should bypass this check. But again, I get the same exception no matter what I use. I checked the bug database but did not find anything.
We are using a made up certificate because we want the data encrypted over the wire, but we can trust the endpoint as it is internal.
Thanks for any thoughts.
Verify that your self made certificate is valid and installed correctly by accessing the endpoint using other software such as curl, wget or a web browser. You might have already done that, but the question does not (yet) say so.
If other software can access the endpoint but the url fetch service still cannot, then please report the problem with a link to your question in the AppEngine Issue Tracker. Thank you.
Is there a way to get whether a mail is marked as important or not from Java Mail API.? I'm using a Gmail account to connect. Thanks in advance.
Different mailers use different ways to indicate that a message is "important". Some use an X-Priority header. Others use an Importance header. I don't know offhand what Gmail uses, but look at the raw headers of a message and you should be able to figure it out. Then use the JavaMail getHeader method to access that header.
I'm writing a RESTful Database Server called Phoenix. Being an easy interface into an entire application's data, security is quite an important issue, and I'm interested in what authentication solutions any of you could suggest.
It needs to be:
Secure - it's got to be very hard to break. Signing requests could be a good way of doing this, but considering it's REST there aren't many parameters that are sent so I don't know what good singing would do.
Minimal - I'd rather it didn't take four requests to compare six tokens in HMAC-signed requests - the USP of the server is it's simplicity, so authentication from clients has got to be easy.
Implementable - it has to fit the system, which is a database server. So, for instance, oAuth wouldn't work here.
I'd love to hear your suggestions - thank you!
Jamie
Not much information here about what your security or implementation needs are. The quick answers are Basic or Digest over SSL, or signed requests. Are there reasons not to use these?
Signing requests typically adds a timestamp and/or a nonce, so any request can be authenticated. See the Amazon AWS authentication documentation for a description and libraries.
I have a similar server. I choose to use OAuth signing for its simplicity,
http://oauth.net/core/1.0#signing_process
We don't enforce the nonce, just limit the timestamp to a short window (30 seconds) to thwart replay.
The OAuth library is available on many platforms so you don't have to write much code to implement it. Don't know why you think OAuth is not implementable.
For each client allowed to access the data, it's assigned a consumer_key and a consumer_secret. All the requests are signed with consumer_secret so only client knowing the secret can get access.
We also considered other options. HTTTP Basic Auth over SSL is too expensive. HTTP Digest Auth is too slow because it needs to wait for a challenge.