I have a sample application created using node js and passport saml strategy for testing SSO with pingFed.
I intend to use SP initiated SSO and created my SP connector in pingFed.
I can successfully login using pingFed and Directory server. However what I observe is every time I try to hit login URL from same browser session I get login prompt. As per my understanding PingFed will create PF cookie and track session and will not prompt me for login.
As verification I verified that my first redirect request http:///idp/SSO.saml2?SAMLRequest= is without PF cookie.
Subsequently when I am hitting /login in my domain , above redirect happens with PF cookie set in request. In spite of that I am always getting login dialog. I am expecting pingFed to use PF cookie and should not try to re-authenticate the user but should exchange SAML token as user already has session established and it is identified by PF cookie.
Is there some gap in my understanding?
Related
Our application offers two login options, via qrcode or via email and password.
For this we have two keycloaks each with a configured Realm.
In the first keycloak we have a client with login via qrcode, which will be an identity provider for the second keycloak.
In the second keycloak, we have a client with login via email and password. In this keycloak we have the identity provider as mentioned above.
Authentication is already working, our problem is in the browser session time, depending on the type of login performed.
We want to have a session time when logged in via qrcode and another session time when logged in via email.
But apparently the only session time the keycloak is using is the SSO Session Max of the second keycloak, regardless of the type of login done.
Is it possible to configure each realm so that each authentication mechanism has a specific session time?
I have Identity Server 4 running ok performing local authentication for an MVC app working fine. I needed to add support for an external IDP too so I followed the instructions in the documentation and based it on the quickstart code. So its currently configured to use the demo IDP at https://demo.identityserver.io as an external IDP and works fine for login - the user gets redirected to the external IDP for entering their details, my auth server gets back an id_token with user id (subject) which I match to a user in our own user repository. Our auth server then continues the login as per normal issuing its own tokens etc. - so all fine so far.
The problem I have is Sign-Out from the external IDP - if a user signs out from the demo.identityservier.io IDP directly, I need to ensure this filters back to clear up the stored authentication cookies thus requiring the user to sign in again if they attempt to access a protected page in the app.
This works ok if the user logs out of our own ID Server (i.e. the logout page presented by the ID Server has built-in iframes that ensure the MVC app gets tidied up). For the external IDP I would expect a similar thing, but cant see anything.
Here's the startup config registering the external IDP within our local IDP startup.
.AddOpenIdConnect("Ext_oidc", "Ext OpenID Connect", options =>
{
options.SignInScheme = IdentityServerConstants.ExternalCookieAuthenticationScheme;
options.SignOutScheme = IdentityServerConstants.SignoutScheme;
options.Authority = "https://demo.identityserver.io/";
options.ClientId = "implicit";
options.ResponseType = "id_token";
options.TokenValidationParameters = new TokenValidationParameters
{
NameClaimType = "name",
RoleClaimType = "role"
};
});
Any suggestions would be greatfully received
Have you provided an end session endpoint URL to the external IDP? If it's defined I'd expect it to be called as part of the explicit sign out process on the external IDP.
In your MVC app use below code in an action an call it to sign out and clear app cookie and ID Server cookies.
Request.GetOwinContext().Authentication.SignOut(Request.GetOwinContext().Authentication.GetAuthenticationTypes()
.Select(o => o.AuthenticationType).ToArray());
I am implementing a SSO using SimpleSAMLPhp Service Provider.
I provided my metadata to remote Shibboleth Identity Provider and was provided a test account.
When a user visits a specific page on my SP, they get redirected to the IdP, login, and are redirected back to my web site with a bunch of IdP provided attributes. This part works.
This part I am struggling with.
If the user authenticates with the same IdP through a different Service Provider and then visits my page, how do I know they are already authenticated? Currently I am being asked to login again.
Is there a configuration value somewhere that lets me do this? Or am I using the wrong method? This is what I am doing.
$as = new SimpleSAML_Auth_Simple({REMOTE_AUTHSOURCE});
$as->requireAuth(); // this redirects to remote IdP login
$attributes = $as->getAttributes();
Thanks.
There are two separate authentication sessions to consider. One session is in you app and the other is at the IdP. The requireAuth method can tell if the user already has an authenticated session in your application, and will return immediately in that case.
There is no way for you to tell if a browser has a session at the IdP. You just call requireAuth whichs send the user there and if the IdP decides the user's session is still valid it will respond without prompting for login.
Are you saying that the user has a valid session at the IdP and they are being re-prompted to authenticate when you send the user there? That could be due to IdP policy, or if your app was sending something like 'forceAuth' in its AuthnRequest.
I am creating simple service provider (SP) on java with wso2 saml sso authorization.
I implemented it in this way (please correct me, if I'm wrong):
User inputs some target Url in browser
My SP's servlet sends redirect to WSO2 IDM.
IDM authorizes the user and redirect to my Consumer Url with
SAMLResponse and RelayState parameters.
Now SP must process this request and redirect user to target Url without redirection to IDM again. Otherwise I'll get the infinite loop, so I think that between step 1 and step 2 should be one more step...
What is the proper way to do this?
Typical implementation
1 User tries to access a protected site
2 A filter checks if the user has an authenticated session.
2.1 If not, redirect to IDP/IDM
2.1.1 IDM authenticates user and redirects back to SP with identity proof
2.1.2 SP creates authenticated session
2.1.3 User is redirected to target URL everything start from 2 again.
Here I have a post describing the flow in more detail
I have a site say www.e1.com. www.e1.com is Service Provider. Whenever I click a service in it, I am redirected to a Identity provider, say www.e2.com. Before that,In service provider(www.e1.com) I will check if any cookie is set for the user. For the first time there will be no cookie so it will send empty SessionId value. Thus, I am sending a SAML Request to www.e2.com along with with no id(as no cookie is set. Cookie contains Id)
Now in www.e2.com i.e.In identity provider,I will check whether www.e1.com has sent any Id value. If it is null I will create a session Id and store it in database(In www.e2.com). Then I will redirect browser to my Authentication page where User's Name and password will be asked and accordingly he will be authenticated. If the authentication is successfull, I will redirect browser to Service provider(www.e1.com) with SAML Response which contains session Id.
Now in Service provider the SessionId value will be stored in Cookie and browser will be redirected to consumer service page(service page the user wants to access).
Now if the same user wants to access some other service from same Service provider
(within the session), the browser will obviously send the SessionId in Cookie along with the request SAML. Identity Provider will check the SessionId value in his database, If its there in its database then it will give direct access to service to user without entering login credential as the user is already authenticated for the session.
Is this the right way to achieve Single Sign On with SAML? or
If this method has flaws, Can you explain those flaws?
Thanks in advance :)
Your understanding is not quite correct :)
Here is the flow:
User tries to access a protected resource on the SP. SP checks if the
user has a local (and authenticated session). If not it generates a
SAML <AuthRequest> which includes a random id. The SP then redirects
the user to the IDP with this AuthnRequest.
The IDP will check if the user has a local authenticated session. If
not it will authenticate the user The IDP will send an AuthResponse
back to the SP with an inReplyTo attribute which matches the id sent by
the SP in it's AuthnRequest
The SP will then create a local session. Subsequent requests to the
SP will not involve the IDP unless a) The session expires or b) the SP
receives a SingleLogout message from the IDP