I'm trying to create a partnership with another organization using SAML for SSO. We have a URL (let's call it https://ourwebsite.com/SAML/AssertionConsumerService that is expecting a SAML assertion Request via POST but instead we are getting a link to the other organization's Metadata being sent to us in the query string.
I've got a ticket out to the partner org, but they don't seem to understand it without going to their developers and it's taking a while.
We've successfully set up SAML partnerships with other organizations, so I know that we're able to consume the SAML assertions properly. I've just never heard of this practice (sending a link to the metadata in the query string) and was hoping someone could shed some light on it for me.
Basically we don't need their SAML Metadata to be sent to us because we store that information for all our partners in our database. MY QUESTION IS - Is this a different approach to SAML that I just haven't heard of, or are they just doing it wrong?
Related
Please help. I'm aware there are several posts / docs about SSO implementations but I still can't seem to find one that addresses my use case - probably because I'm still new to SSO implementation.
Scenario:
I have an existing Symfony 4 application with existing users. I want so that when users log into the app, they are automatically signed into Outlook Office 365 (web). Exactly the same implementations on https://mysso.centennialcollege.ca/. Please NOTE I do not want office 365 to authorize my app using the code flow approach, rather I want office 365 to recognize users signed into my app as valid identities.
Has anyone implemented this or has ideas please?
Your question is a bit unclear. You're likely going to need to change the existing application in some manner in order to achieve true single sign-on. You'll need to ensure that authentication against the Symphony app leads to the presence of a session that can be used to trigger subsequent sessions in a SSO framework supported by O365.
In your case, I'd take a look at SAML and, more specifically, SimpleSAMLphp.
Are you affiliated with the organization you linked to in some way? Because just by looking at the login page that looks like they've already got some sort of SAML Identity Provider solution... you can just integrate your Symphony app with that IdP in that case, and correlate the principal returned to your SP application from the SAML assertion on successful authentication against the user data in your existing DB. You wouldn't have to use SSP in that case... any kind of SAML middleware would work.
So I want to understand a little more about authentication in an API. I know very little about how security works.
I am using Auth0 for my app and it supports only logging in from a social media site. My API checks if a user is authenticated and checks data that is being sent to avoid wrong stuff to be saved in the database(mongodb). That is all I have currently implemented to secure my API. Is it possible that a user can take his own token that he got from logging in and post information to a different account by simply guessing a different user _id.
For example, an article receives all its content and the id of the article author.
If this is possible what are some solutions on securing my API.
Any other tips on making an API secure are appreciated!
Auth0 supports logins with anything , not just social networks. You can login with username/passwords, LDAP servers, SAML servers, etc.
A token is a secure artifact. An author cannot change the id in a token without compromising the token itself (e.g. the digital signature will fail), so impersonating someone else is not that easy. The very first thing your API would need to do is checking the integrity of the token being added to the request, and reject any that contains an invalid one (bad signature, expired, etc).
It is a question that requires a lot of content, so I would recommend starting here: https://auth0.com/docs/api-auth
After reading a few articles on SAML, including "SAML for dummies," and the SAML wiki article, I'm still entirely unclear as to how SAML actually solves the SSO problem. Suppose I take something like a Google account as an example. My understanding is that if I go to GMail and SAML is implemented, I will be redirected to an IDP, which, let's say, is Google's sign-in authority. My browser then goes there with a redirect, and I'm asked to log in. After providing the correct login info, I return to GMail with a token and SAML response encrypted with Google Sign-in's private key, which is then authenticated using GMail's public key, thus verifying that I am, in fact, who I say I am.
What's confusing to me, is that this seems to solve the problem of signing in the first time, or into a single application, but I don't understand what happens when I now go to Google Drive. Even if my browser saves the SAML token/response as a cookie, I would have to sign in again after the token expires, which, I read, is something like 2 minutes later. Moreover, even within the same application, requests to separate resources or endpoints seem like they would time-out in the same fashion.
The only hint I have is that, according to the wiki article, step 1 has the target resource at the SP check for "a valid security context." However, if GMail and Drive are separate applications which aren't communicating with each other, how would Drive know that I already have a valid security context?
Questions:
After the initial authentication, what information needs to be sent with future requests to the same or different application/endpoint? For example, perhaps the SAML assertion saved and resent with every request.
How is this information secured/verified?
What timeouts are associated with SAML's SSO, and how are the timeouts enforced on both the SP and IDP sides?
What you are missing is that the Idp (Google's sign in page in your example) sets a session cookie on the first login. When you access Google drive as the second application, it has indeed no knowledge of the gmail session. Google drive does a redirect to the idp to get an authentication.
Now, the idp has an active session thanks to the cookie on the idp domain. That makes it possible for the idp to reply to google drive with a new assertion, generated from the persisted session information.
You're right that each assertion is normally only valid for a few minutes, but that isn't a problem as the idp can create a new assertion for each application.
For timeouts: The Idp can set a SessionNotOnOrAfter condition in the assertion to tell the SP that it must terminate the session at a given time.
BACKGROUND:
My company is acting as the Service Provider to our clients that are the IDP. We use OpenAM, but our clients use ADFS or Shibboleth. We exchange metadata files for establishing federations, not URLS. A client asked why we require an AuthnContext class schema (specifically PasswordProtectedTransport), and not only do we not know why, we don't know how to change it or what that would mean.
QUESTION:
What is the functional difference between using "PasswordProtectedTransport" vs "unspecified" for the AuthnContextClassRef in a SAML2 assertion?
We currently use PasswordProtectedTransport amongst all our clients, but no one at my company can tell me why we require this. If we remove it, the federation stops working with a 500 error and a "NoAuthnContext" in the SAML trace. We also don't understand that, as I was led to believe from SAML documentation that having a schema is optional for the authentication. Even so, I saw no explanation anywhere of what the implications of using "unspecified" would be.
I can’t find any thorough explanation or discussion anywhere about this topic and was hoping someone could elaborate for me, as I am struggling to find light on this.
RequestedAuthnContext in a request is a mean for a SP to ask the IDP to authenticate the user with a specific authentication mechanism.
For example, if you specify PasswordProtectedTransport in your request, the IDP knows it has to authenticate the user through login/password, protected by SSL/TLS.
The IDP says in its response which mechanism it used to authenticate the user through AuthnContextClassRef.
RequestedAuthnContext in a request is optional, but AuthnContextClassRef in the assertion is mandatory as specified by the SAML schema (hence the 500 error you encountered).
Basically, the unspecified URN is used by the IDP to say "I don't want to tell you how I identified the user".
As a SP, you have the choice to accept that answer or reject it, if you want to ensure that the user is authenticated with a secure mechanism.
I am trying to implement SAML Based SP Initiated Single-sign on using openSSO. Post the authentication request validated on IdP side, it passes the SAMLResponse via post redirect to
spAssertionConsumer.jsp to SP. Till this point I am getting the SAML Response. As we are using Sun Java System Web Server, I have installed the respective policy agent, and in Session Attributes Processing I have mapped the required attributes as well.
I have mentioned the Relay State URL as my application URL which is a separate domain from the openSSO installed one. When the response getting redirected from openSSO to our application I am not getting any SAML Assertion attributes in request header or Cookies.
I am not sure what probably would have gone wrong here> If anyone provides some clarification on it, its highly helpful. Thanks.
In order to debug de SAML flow I recomend you to use the [SAML Tracer plugin for firefox][1]
There are a lot of things that could be failing. Review that the IdP is sending a SUCCESS status, that the assertion of the response has the expected attributes, check that the response is valid, check if is there any sign or encryption that the SP can't handle
If not wrong data detected, I recomend you to create a basic app under the domain of the openSSO and check if this app retrieve the attributes, due other problem that could been happen is that you final app is not getting the attributes due can't read the session that was stored by OpenSSO.
Usually the SP software is located at the same machine of the final software in order to share the session...but you could store the session at the OpenSSO at a shared memcached server that is accessed by your final app
[1] https://addons.mozilla.org/es/firefox/addon/saml-tracer/