I have created 2 different maven web applications and both of them have been hosted as different clients in the same realm. Both of them are hosted in my local machine on JBOSS EAP 6.4.7 server. If a user tries to login to the first application, he perfectly logs in through keycloak and keycloak maintains a session for that user. Now if the same user hits the login page of the second application, he automatically logs into the second application as he already has an active session in keycloak. Is there a mechanism to restrict the user from logging into second application even though he has an active session through application 1?
This is needed to secure the multi-tenant architecture of my application where the application is accessible through multiple urls for different customers and I do not want the user of customer1 to login into customer2 if he is already logged into customer1.
Related
I have an SPA web app using openidconnect for authentication and authorization with local keycloak.
This app is now moving to an windows onprem infrastructure using AD, kerberos tickets and a central SSO.
users log in in their windows session, and then we shall be able to transparently login in our SPA web app. (ie with out entering credentials)
How can I convert kerberos ticket/authentication into Openidconnect world? Where is the magic?
Shall we add some kerberos in our app?
how can we retrieve our access token containing the user role?
thanks
Your SPA should continue to talk to Keycloak using OIDC, and no code in the SPA should need to change. Your APIs will also continue to receive the same access tokens.
You should only need to configure Keycloak to use AD for authentication as an LDAP data source. Here is an article on how to do that. It is an infrastructure job rather than just a coding one, so I would recommend collaboration with AD administrators on the environment setup.
AD is only one possible authentication method, and by doing things this way you keep your options open. You are likely to need to perform account linking, eg to identify users the same before and after the migration. There may be some data setup involved here, eg ensure AD has the same emails as the existing system.
We have G-Suite that is used as an SSO for most of our corporate applications, all users are internal users.
but we introduced KeyCloak in order to manage the security for all applications, exposed portals, internal users, as well as all external users.
I need a way to keep syncing the Users from G-Suite to KeyCloak, so KeyCloak will manage all users\groups\permissions for internal and external users.
Also I need to know how I can provision\de-provision users from KeyCloak where it shall be reflected on G suite as well.
Note: OKTA can do that.
I have an authentication server using oauth2.
I use it for :
Authentication from the other services, subscription, change and retrieve password etc.
As resource server to store and retrieve more users and groups informations. I have a ManyToMany relationship between users and groups.
Should I seperate the second part of functionalities of this app on another standalone service that will work as resource server only. And only keep the authentication part on the authorization server?
That way I could horizontally scale these two services separately.
Yes, the better idea would be to have the configuration as a separate standalone service running on cloud. With configuration server as a separate service you can add all the authorization and other sort of details like DB details, API details, messaging queue configuration etc, and get connected to N number of services.
I am implementing a typical classical SSO between 2 websites, on 2 different domains. One website (let's call it site1) is developed and hosted by a partner, the second website (let's call it site2) is developed and hosted by me.
I use the partner ADFS as an Idp.
I installed and configured Shibboleth SP3 to manage the authentication on site2: when I try to access site2, I am correctly redirected to the ADFS and it works.
My concern is, the end-user will authenticate to site1 first, then along the way access site2, and we don't want him to authenticate again.
I have few questions about this, how I don't know how to proceed:
- do I need the same instance of Shibboleth SP3 to manage authentication on both sites, to manage the cookie / headers, or can I use different instances (in that case, I would use Shibboleth for site2, and the partner will use another SP for site1)
- how to manage the redirection from site1 to site2 ? Can it be a request.redirect? Should site1 send a post or get request, with specific parameters?
Thanks !
If the partner is hosting site1, they should be running Shibboleth on that instance, and integrate with the IdP the same as you on your instance running site2.
The whole purpose of SSO is that they don't need to re-auth. i.e. User visits site1, redirected to login on ADFS, auth (user is picking up IdP session), redirected back to site1 which validates the auth token (SAML assertion) and shows them the content.
Now, when they are pushed to site2 (by whatever means), site2 fires off the authnrequest to the ADFS server as a redirect with the user, but this time the user already has the ADFS session, so the ADFS server just issues the SAMLResponse. They don't make the user log back in.
This is only because both SPs are integrated with the same IdP.
You can redirect the users around however they want in this instance... but it means running instances of Shibboleth on both web servers. If you really wanted to only use one Shibboleth instance, you could create a SAML broker, where one webserver brokers the SAML assertion on behalf of another, but that's kind of silly. Easier to just run to Shib installs when it's two disparate servers.
If both sites live on the same server, you can do the same thing, basically... each site is a separate host on on the webserver, and you just need to configure each site (one as a default, and another as an Application Override) though you probably don't even have to go that far TBH. You'd only need to have separate ApplicationOverrides if you wish to, say, integrate site 1 with IdP_A and IdP_B, but site 2 with IdP_A and IdP_C. See: https://wiki.library.ucsf.edu/display/IAM/Steps+to+configure+multiple+context+in+Shib+SP
I want to create a POC which demonstrate the SSO between two different application hosted on the different server and different machine(1.e. App-1 :- Websphere App server 7.0.0.15 and App2 :-Jboss 6.2 EAP).
Both the application share the same LDAP (user repository) so user can navigate from One Application to Another application (App-1 to App-2 or vice versa).
Please suggest me which SSO technique would be feasible in such setup.
If they apps are not deployed in the same cookie domain (check https://www.rfc-editor.org/rfc/rfc6265) or deployed in a public suffix (https://publicsuffix.org/) you can not use an SSO mechanism based on cookies unless the 'product' offers a way to perform CDSSO (like OpenAM). Then you may need to use 'SAML2' or 'OAuth2/OIDC'.