I am currently going through OneLogin's documentation.
There is one point that remains unclear to me.
I think I understand the main differences between SAML and OIDC.
However on the SAML description it seems that there is no authentication required from the end user.
Compared to the OIDC description, where a code is required from the end user.
This point only would make me lean toward SAML as it is "frictionless".
My questions are -knowing that I want to integrate with OneLogin-:
Is SAML "frictionless"? Can it be?
Is OIDC "frictionless"? Can it be?
If so, is it a specific OneLogin feature? (It seems that all the documentation that I found online mention authentication with the IdP)
Thank you for your help!
The article states:
"The user either has an existing active browser session with the identity provider or establishes one by logging into the identity provider."
So the user has to authenticate if no existing browser session.
The article is around SSO i.e. if you have already logged into an IDP with SAML and you access another application on that same IDP, you won't have to login again.
OIDC has the same approach.
OIDC can be "frictionless" if you use the Resource Owner Password flow where you pass the user name and password under the hood. The user does not have to authenticate.
But it's deprecated in OAuth 2.1 as it's not secure.
Related
I have implemented a shibboleth idp (myidp.example.com) on my own server with password flow. They authenticate with their username and password against database MySQL.
At this point, everything is fine.
But now I want to add one more login flow: SAML. I want to allow users to choose either login in by username/password or through another idp (idp.anotherwebsite.com). It's up to them to choose which method to login.
I've read through the entire shibboleth wiki, but it seems none of the articles mentions about my use case.
Can someone point me some direction?
You have implemented one idp.
Now for authentication page, you might need to implement one SP.
This is a normal usecase. Search for Federeted login.
Softwares like KeyCloak may help as well
I'm part of a small team as a nodeJS dev and I've been tasked into researching how this can be accomplished. I'm fairly new to OAuth and authentication so please bear with me.
Currently we have a next.js webapp that uses NextAuth for authentication with the user store in DynamoDB. What we want to do is provide an Oauth2 flow so a user can consent to a 3rd party service having access to their profile information via an endpoint. In this case we are the resource server, the 3rd party is the "client" and our user is the resource owner.
The piece of the puzzle I'm trying to put together is how does Auth0 work with NextAuth in this scenario? I want Auth0 to check if the user is logged in (otherwise prompting them to do so) via NextAuth, and for NextAuth to say "this is fine" and then for Auth0 to issue a token to the 3rd party (concluding a "normal" OAuth flow). Is this were SAML comes into play? I see there's a software package called SAML Jackson (lol) and there's a Next-auth integration for it.
Most examples I see usually work the other way around, with Auth0 as the identity provider, and what we're doing may be unique. Sorry if this question comes across as abstract but that's how it exists in my mind currently. Any help understanding this would be greatly appreciated.
You can connect your user store to Auth0 as a custom database connection. And then create an application inside Auth0 and enable the DB connection for the app. This way Auth0 acts as the Authorization server for your client app.
NextAuth.js is just an authentication library that supports the OAuth2.0/OpenID protocols. The role of NextAuth is simply to initiate the authentication flow, take the user to the Identity Provider (in this case Auth0 backed by a custom user store) and finally process the authorization response from Auth0. The authorization response (code) is received at the application end and then exchanged for access_token and user profile (all handled by NextAuth.js).
And for your query on SAML, it's a standard for exchanging identity information between two parties an Identity Provider (IdP) and a service provider (SP). The same is achieved by its more modern counterparts OAuth2.0/OpenID Connect. Typically third-party apps which are deployed in an enterprise setting use SAML to integrate with on-premise Identity Management Systems like ActiveDirectory. You can read more about SAML on https://boxyhq.com/blog/understanding-saml-sso-the-basics-from-the-user-side.
I have two service providers set up with one IdP and users are required to be authenticated twice to access both services at the same time. From my point of view, this is not "SSO" and I am thinking that there might have been settings done incorrectly and I would like to see if the community here can provide me with directions and/or possible solutions.
Just a thought - the behaviour for the authentication on each service looks valid as I understand that IdP is required to send signed SAML assertions to the providers in order to access the services. However, because I only have one IdP, can I not be authenticated just once and be able to access all the services?
Any suggestion is appreciated. Thanks.
Typically in this scenario the user would authenticate once to the IdP when the first SP SSO's to it. There would be no authentication at the IdP when the second SP SSO's to it as there's already an authentication session at the IdP for the user.
However, there might be use cases where you want the user to be authenticated at the IdP even if they already have an authentication session. The SP can set the ForceAuthn flag in the SAML authn request sent to the IdP. This requests that the IdP authenticates the user regardless of whether or not they already have an authentication session.
ADFS also has a configuration option for relying parties (SPs) to always require authentication. Take a look at the AlwaysRequireAuthentication flag.
https://learn.microsoft.com/en-us/powershell/module/adfs/set-adfsrelyingpartytrust?view=windowsserver2022-ps
I am implementing front-channel SAML 2.0 SSO golang Service Provider, with Okta as my Identity Provider (this is just a POC and should eventually work with any IdP).
Implementing the sign on process was straightforward with saml2 package. I've created the login endpoint that redirects to the SAML application login URL at the intended IdP, as well as the POST callback endpoint which is properly receiving the SAML assertion and is able to validate it. After that a session with a random cookie is created with the same TTL as the Identity Provider session TTL. So far everything works well (I haven't implemented Single Sign-Out yet, but I'm planning to).
However, when some time passes and the session expires, I'd like to renew it only if the user is still logged in with the Idp and hasn't been removed from the SAML Application. I would like to avoid redirecting the user to perform SSO again with IdP, because it would mean that if they are still logged in, they would be redirected back to the home page of my application. I wasn't able to find great sources on my options to go about it online.
Questions:
1.1 One solution that comes to mind is storing the requested URL in the RelayState parameter, whenever the session has expired, then redirect the user to the IdP SSO URL. When the redirect returns to the SAML callback POST endpoint, check the RelayState parameter and if set, redirect back to that (original) URL. That means that for users that use the system continuously, I would have to request Assertions very often. Does that make sense?
1.2 A second solution that comes to mind is to implement a back-channel of communicating directly from my SP to the IdP. That would allow me to verify a user is still logged in 'behind the users back'. If that's a sound idea:
a. Do I need to have dedicated code for each IdP?
b. Do I need to load an API key to the IdP which would allow secure communication?
c. Do I need to upload a public certificate to the IdP that would be able to verify that my SP signed the requests?
Will using the Assertion to get an OAuth 2.0 Access Token help me in achieving this?
I've chosen SAML 2.0 for now, since the environment is an enterprise oriented one and I thought it fits well with it based on what I read. Would using OpenID Connect instead help achieve my goals easier and fit well with enterprise oriented products?
First of all I do not have any experience with SAML (version 2).
I was asked to investigate how we can make an existing site, which has a normal login page with a username and password page, ready for SSO with SAML.
There are some tools around which we can use in order to do this.
So I think it is not so difficult to implement the SSO part.
But however it is not clear to me how the authorization is managed.
The system (web site) is using authorization rights in order to determine if the user is able do access certain parts and if he does, the right type he has (view, create or edit).
These rights are assigned to each user by an administrator in the system itself.
When a user logs in the system by specifying his credentials (without SAML/SSO) his rights are also retrieved.
How is this done when a person logs into the site by using SSO?
Is there a mapping of the userId which is know by the IdP (Identity Provider) to the userId which is know by our system?
And is this send in the SAML response from the IdP?
Or is this done in another way?
Thanks in advance
SAML is mainly a authentication protocol but there are still many ways to solve this. SAML supports sending authorization infromation in AuthzDecisionStatement in the assertion.
Another alternative is to extend SAML using XACML which is a big framework for transferring Authz information.
However the support for these are limited in many SAML providers.
The simpler solution and probably the best in your case, if it is just one access right per user, is to send it as an attribute in the SAML assertion. This can usualy be mapped against for user properties.