Maybe that's a wired question.
I want to send AuthNRequest to idp with certifecate and ipd will deny all unauthenticated requests.
My sp metadata configured with a pair of public and secret keys.
IDP metadata configured with the sp public key.
And I've created two AuthNRequests:
first with a public key and the second without.
But for both, I'm receiving the same result (connection established)
I would like that IDP will deny all requests, coming from sp, without recognizing the authentication of the sp.
Is there any way to do that?
I'm using pingone and okta IDPipds.
Thanks.
Related
I've been provided a metadata.xml file from a client who is using ADFS, and had some questions getting this configured as an external SAML-based IdP. This is going to be integrated with a web application (LAMP stack, if that's relevant).
1) Can I extract the IdP Issuer URI from this xml file? I see entityID in the file, which is something like "http://sts.blablaba.com". Is this the same thing, or is this something I need to get separately from the client? Is this the same as "Relying party trust id"?
2) I see an <X509Certificate> element that looks like a public key. Is this the signing cert i need to verify the saml messages/asserts? Can I just copy/pasta this into a .crt or .pem file? "DigestMethod", "DigestValue" and "SignatureValue" are also present.
3) With an oauth2 flow, for instance, since it starts at the site, i can store redirects in a session, and send users to different pages depending on what they were initially trying to access. It seems like this would be possible with an SP initiated flow, but the client says this is going to be IdP initiated. Is this type of post-login dynamic page redirection still possible, considering that the Relay State looks like a static value?
I'm knew to SAML and i'm trying to understand how a clients details are stored for SSO.
If select a link in a browser to a service provider and I haven't been set up on the IDp after I have my account created at the IDp and authenticated to the SP what is stored? is it my ipddress? if I tried to connect to the same SP from a different machine would I need to be registered on the IDp again.
Or is it done another way?
Thank You
An IdP creates a SAML assertion about an authenticated subject.
Based upon the NameID format being used an opaque handle could be transmitted ("transient NameID format") or an email address ("email NameID format") or even some other id can be transmitted from the IdP to the SP. Furhtermore attribute statements could be used to transmit additional information about the subject.
Authentication happens on the IdP, however it's not defined in the SAMLv2 spec how this has to take place.
If authentication happened a "session" is established at the IdP. Most IdP implemenatations use a cookie to track the "session". So when you return to the IdP again there is no need for re-authentication unless an SP mandates this. ("ForceAuth" in the SAML AuthnRequest).
This is only a quick overview, reading the SAMLv2 tech overview (https://wiki.oasis-open.org/security/Saml2TechOverview) certainly gives you more insights.
I am developing SAML2 Service Provider capability (supporting IdP-Initiated SSO).
I understand the general flow is:
1) User authenticates at the IdP.
2) User launches to my SP via an HTTP POST to my SAML endpoint - containing XML token.
3) My SP's Assertion Consumer Service eats that token up, verifies it and logs said user in.
What I don't understand is the certificates / Private Key parts. I understand that the IdP shares a certificate with the SP, and that the certificate is used to verify a SAML token when it arrives... but, I can't find any detail on this (except the official SAML spec, which I really struggle to understand).
My q's are:
1) Who creates the certificate? The IdP or the SP?
2) Who creates the Private Key? The IdP or the SP?
3) How does the Key relate to the certificate?
4) How are the key / certificate shared?
5) How are the key / certificate created?
So, as you see, I just want a PK / Certificate for dummies explanation. In terms of who creates them / how they're created / where they're stored etc...
Many thanks,
The private key would be used by the IDP to sign the SAML tokens that are being generated and sent to the SP. The SP would use the public key certificate to validate the signature in the SAML token.
The private-public key pair will be created by the IDP and the private key kept on the IDP server for use during signing. The public key would be given to the SP as part of the metadata.
I would suggest you read through PKI articles to understand details of a PKI setup. The storage of private keys is very critical since they are used to guarantee that the tokens are not being tampered with.
I am trying to understand the SAML 2 protocol and in that process got a little bit lost with the signature and certificate business.
Basically, I am not clear of when each of the certs are used.
Service Provider Meta Data and Identity Provider Metadata - do we need to generate certificates/keys as a part of the SP and IDP metadata? If so how/when will these certs be used?
HOK token also needs a certificate - when does that come into picture? Does the principal's certificate/public key needs to be exported to the IDP also along withe SP's certificate?
When using bearer tokens (they do not have any certs associated with the principal) is the SAML response/assertion still signed? Is it different from the ds:keyInfo in the SAML response in this case?
Thanks a bunch for the help!!
1.
Certificates in SP and IDP metadata are typically used for two purposes digital signing and digital encryption. Attribute "usage" on metadata makes the discrimination. Certificates are typically included in the metadata, but they could also be ommited and provided out-of-band (e.g. by direct configuration in IDP and SP, if supported). These keys identify the SP and IDP machines, they have nothing to do with the users.
When SP sends a SAML message towards IDP the message can be digitally signed using SP's private key (whose public key + certificate is included in the SP metadata and available to IDP), IDP is able to verify the SP's signature using the SP's public key.
When SP wants to encrypt part of the SAML data (whole message, assertion, name ID, attribute, ...) it uses public key declared in the IDP's metadata, IDP then decrypts the data using its private key.
Sometimes metadata can contain multiple signing or encryption keys, e.g. in case of certificate rollover before expiration.
2.
Bearer mechanisms are used to make sure that the entity (e.g. web browser) who is presenting a SAML message is allowed to do so. In SAML WebSSO AuthnResponse message gets issued by the IDP, but is delivered to the SP by the browser. HoK SubjectConfiguration tells that we are identifying the presenter by making sure that it can prove posession of a private key whose public key/certificate is included in the SubjectConfirmation element. This is typically done by usage of SSL/TLS Client Authentication (i.e. user installs private key in browser and uses it to authenticate toward SAML service when opening the HTTPS scheme with SSL/TLS).
So here we are dealing with keys issued directly to users, not to SP/IDP services. Whether or not you need to import user's certificate(s) to the IDP or not is IDP-implementation specific.
3.
Yes, the messages will still be signed (when configured to be) and KeyInfo in the SAML response will be the same in both cases.
Cheers,
Vladimir Schafer
Scenario:
Browser(User) requests resource from Service Provider (SP).
SP Redirects (with SAML Request) to Identity Provider (IdP).
Since it is first login, User gives the (IdP) his/her valid credentials.
IdP then redirects Browser (with SAML Response which includes SAML token) to the SP page.
I have two questions:
A. In Step 4, does the Browser store or cache the SAML Response and/or SAML token?
B. If yes, what kind of things (attributes? timeouts? protocols?) prevent me from taking that stored SAML token. Then coping it over to another computer (with a new session) and using that token to Login to the same SP?
The answer is "sort of" re caching. In your scenario, the Response will be sent via POST to the Service Provider from the browser. So the browser can "cache" the POST data that contains the SAML Response. So, just like any other POST event in browsers, if the user were to use the back button enough times after logging into the SP to get back to the POST event, the POST data could be resent to the SP.
There are a few things that help keep the Response from being hijacked -
Use of HTTPS between all parties
SP enforcement of NotBefore & NotOnOrAfter attributes
SP enforcement of one time use criteria (the SP must ensure that Response is not re-used during its validity period. If the message is received outside the validity window, then the SP should discard the message)
The IDP usually stores a session cookie on the client browser identifying the SAML session. The theft of this session cookie is probably no more protected then any other session cookie.
Using HTTPS in communication between SP and IDP will provide a great deal of protection from session hijacking.
For question A, it probably depends on the browser that you use.
For question B, there are several mechanisms that prevent the SAML response from being reused:
SubjectConfirmationData has attribute NotBefore and NotOnOrAfter that specify the time frame that the SAML assertion is valid. Thus, the SAML assertion cannot be used outside of this time frame.
SubjectConfirmationData has attribute InResponseTo that specifies the SAML request for which the SAML assertion is issued. Thus, the SAML assertion cannot be used for other SAML request.
SP must ensure that the SAML assertion is not replayed by maintaining a set of used SAML assertion.
You can read Section 4.1.4.3 and 4.1.4.5 of SAML Profiles specification.
I know this old, but the answer is yes the browser stores the SAML Token as a Cookie. (Typically) You can see it in your Browser's Cookie list, through various traffic/session inspectors like Fiddler, SAML Tracer on FF etc.