There are some concepts relating to SSO - single sign on in software applications.
OAuth introduces an authorization layer and separates the role of the client from that of the resource owner. In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server and is issued a different set of credentials than those of the resource owner. Instead of using the resource owner's credentials to access protected resources, the client obtains an access token; a string denoting a specific scope, lifetime, and other access attributes. Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.
OAuth roles:
In any OAuth 2.0 flow we can identify the following roles:
Resource Owner: the entity that can grant access to a protected resource. Typically this is the end-user.
Resource Server: the server hosting the protected resources. This is the API you want to access.
Client: the app requesting access to a protected resource on behalf of the Resource Owner.
Authorization Server: the server that authenticates the Resource Owner, and issues Access Tokens after getting proper authorization. In this case, Auth0.
Protocol flow
may think that, OAuth is going to authorize functions for software applications.
It is simple to think that Keycloas will be equal to OpenID + OAuth
Keycloak offers features such as Single-Sign-On (SSO), Authentication, Authorization and an Account Management Console.
How to install and using Keycloak? The link https://www.keycloak.org/docs/latest/getting_started/ is a good beginning for everyone.
Client Access Types
When you create a Client in admin console you may be wondering what the "Access Types" are.
Client Authentication with Signed JWT
Until version 1.4 the confidential OpenID Connect client applications can be authenticated just with client ID and client secret. Client secret is shared between client application and Keycloak server and hence is known to both parties.
From the 1.5 version, we added support for authentication with private/public key pair. It's based on the RFC 7523 . The client authentication works in a way, that the client/adapter generates the Json Web Token (JWT) and signs it with his private key. The Keycloak server then verifies the signed JWT with the client's public key and authenticates client based on it.
The private key of client can be generated by Keycloak server and saved to keystore file on client side, or you can use existing private key of client and upload just certificate/public key to Keycloak server. In both cases, there is just client certificate and public key saved in Keycloak database.
There is increased security in this kind of client authentication in comparison to client secret, as the private key of client is not saved in Keycloak database and it's not sent over the network during client authentication.
More than that, we added support for pluggable client authentication. So if it's still not sufficient for you to authenticate your client with client secret or with signed JWT, you can implement and plug your own authenticator and configure it in admin console . See docs for more details.
Client Authentication with Signed JWT using Client Secret
This is the same as Client Authentication with Signed JWT except for using the client secret instead of the private key and certificate.
SSO Protocols
There are two SSO protocols: OpenID Connect and SAML
OpenID Connect
SAML
SAML 2.0 is a similar specification to OIDC but a lot older and more mature. It has its roots in SOAP and the plethora of WS-* specifications so it tends to be a bit more verbose than OIDC. SAML 2.0 is primarily an authentication protocol that works by exchanging XML documents between the authentication server and the application. XML signatures and encryption is used to verify requests and responses.
There are really two types of use cases when using SAML. The first is an application that asks the Keycloak server to authenticate a user for them. After a successful login, the application will receive an XML document that contains something called a SAML assertion that specify various attributes about the user. This XML document is digitally signed by the realm and contains access information (like user role mappings) that the application can use to determine what resources the user is allowed to access on the application.
The second type of use cases is that of a client that wants to gain access to remote services. In this case, the client asks Keycloak to obtain an SAML assertion it can use to invoke on other remote services on behalf of the user.
How to get user information from KeyCloak server in Securing your Java Servlet Application with Keycloak ?
It is easy. In Servlet application, we add the following to the pom.xml:
<dependency>
<groupId>org.keycloak</groupId>
<artifactId>keycloak-core</artifactId>
<version>4.8.3.Final</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.keycloak</groupId>
<artifactId>keycloak-adapter-core</artifactId>
<version>4.8.3.Final</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.keycloak</groupId>
<artifactId>keycloak-adapter-spi</artifactId>
<version>4.8.3.Final</version>
<scope>provided</scope>
</dependency>
and in servlet code, we add following import
import org.keycloak.KeycloakPrincipal;
import org.keycloak.KeycloakSecurityContext;
import org.keycloak.TokenVerifier;
import org.keycloak.common.VerificationException;
import org.keycloak.representations.AccessToken;
import org.keycloak.representations.IDToken;
and the finally, we use keycloak api to get user information return from Keycloak server:
KeycloakPrincipal principal = (KeycloakPrincipal)request.getUserPrincipal();
String user = "no-name";
AccessToken accessToken = principal.getKeycloakSecurityContext().getToken();
user = accessToken.getPreferredUsername();
response.getWriter().println("Hello World! " + user);
Now, open web browser and type into address bar http://localhost:8081/SimpleServlet-1
then we go to login screen:
We can see that servlet client has received user_name returnning from Keycloak server, it's name is 'tester'.
SSO with Keycloak is easy and effective. Other SSO open source framework is CAS but It is more difficult than Keycloak framework.
KeycloakServer
https://medium.com/@venkateshpnk22/single-sign-on-in-cas-server-with-java-spring-security-
78bd5c45ac29
https://github.com/apereo/cas-overlay-template/tree/5.1
https://apereo.github.io/cas/5.1.x/installation/Configuration-Properties.html
https://mkyong.com/tomcat/how-to-configure-tomcat-to-support-ssl-or-https/
What is OpenID?
OpenID allows you to use an existing account to sign in to multiple websites, without needing to create new passwords.
You may choose to associate information with your OpenID that can be shared with the websites you visit, such as a name or email address. With OpenID, you control how much of that information is shared with the websites you visit.
With OpenID, your password is only given to your identity provider, and that provider then confirms your identity to the websites you visit. Other than your provider, no website ever sees your password, so you don’t need to worry about an unscrupulous or insecure website compromising your identity.
So when talking about OpenID it means we are talking about authentication topics.
So when talking about OpenID it means we are talking about authentication topics.
What is OAuth?
OAuth 2.0 is a protocol that allows a user to grant a third-party web site or application access to the user's protected resources, without necessarily revealing their long-term credentials or even their identity.OAuth introduces an authorization layer and separates the role of the client from that of the resource owner. In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server and is issued a different set of credentials than those of the resource owner. Instead of using the resource owner's credentials to access protected resources, the client obtains an access token; a string denoting a specific scope, lifetime, and other access attributes. Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.
OAuth roles:
In any OAuth 2.0 flow we can identify the following roles:
Resource Owner: the entity that can grant access to a protected resource. Typically this is the end-user.
Resource Server: the server hosting the protected resources. This is the API you want to access.
Client: the app requesting access to a protected resource on behalf of the Resource Owner.
Authorization Server: the server that authenticates the Resource Owner, and issues Access Tokens after getting proper authorization. In this case, Auth0.
Protocol flow
may think that, OAuth is going to authorize functions for software applications.
What is Keycloak?
Keycloak is an open source Identity and Access Management solution aimed at modern applications and services. It makes it easy to secure applications and services with little to no code.It is simple to think that Keycloas will be equal to OpenID + OAuth
Keycloak offers features such as Single-Sign-On (SSO), Authentication, Authorization and an Account Management Console.
How to install and using Keycloak? The link https://www.keycloak.org/docs/latest/getting_started/ is a good beginning for everyone.
Client Access Types
When you create a Client in admin console you may be wondering what the "Access Types" are.
- confidential
Confidential access type is for clients that need to perform a browser login and that you want to require a client secret when they turn an access code into an access token, (see Access Token Request in the OAuth 2.0 spec for more details). The advantages of this is that it is a little extra security. Since Keycloak requires you to register valid redirect-uris, I'm not exactly sure what this little extra security is though. :) The disadvantages of this access type is that confidential access type is pointless for pure Javascript clients as anybody could easily figure out your client's secret!
- public
Public access type is for clients that need to perform a browser login and that you feel that the added extra security of confidential access type is not needed. FYI, Pure javascript clients are by nature public.
- bearer-only
Bearer-only access type means that the application only allows bearer token requests. If this is turned on, this application cannot participate in browser logins.
- direct access only
You would also see a "Direct Access Only" switch when creating the Client. This switch is for clients that only use the Direct Access Grant protocol to obtain access tokens.
When a confidential OIDC client needs to send a backchannel request (for example, to exchange code for the token, or to refresh the token) it needs to authenticate against the Keycloak server.
By default, there are three ways to authenticate the client:
- client ID and client secret,
- client authentication with signed JWT,
- or client authentication with signed JWT using client secret.
Client ID and Client Secret
This is the traditional method described in the OAuth2 specification. The client has a secret, which needs to be known to both the adapter (application) and the Keycloak server. You can generate the secret for a particular client in the Keycloak administration console, and then paste this secret into the keycloak.json file on the application side:
"credentials": {
"secret": "19666a4f-32dd-4049-b082-684c74115f28"
}
Until version 1.4 the confidential OpenID Connect client applications can be authenticated just with client ID and client secret. Client secret is shared between client application and Keycloak server and hence is known to both parties.
From the 1.5 version, we added support for authentication with private/public key pair. It's based on the RFC 7523 . The client authentication works in a way, that the client/adapter generates the Json Web Token (JWT) and signs it with his private key. The Keycloak server then verifies the signed JWT with the client's public key and authenticates client based on it.
The private key of client can be generated by Keycloak server and saved to keystore file on client side, or you can use existing private key of client and upload just certificate/public key to Keycloak server. In both cases, there is just client certificate and public key saved in Keycloak database.
There is increased security in this kind of client authentication in comparison to client secret, as the private key of client is not saved in Keycloak database and it's not sent over the network during client authentication.
More than that, we added support for pluggable client authentication. So if it's still not sufficient for you to authenticate your client with client secret or with signed JWT, you can implement and plug your own authenticator and configure it in admin console . See docs for more details.
Client Authentication with Signed JWT using Client Secret
This is the same as Client Authentication with Signed JWT except for using the client secret instead of the private key and certificate.
SSO Protocols
There are two SSO protocols: OpenID Connect and SAML
OpenID Connect
OpenID Connect (OIDC) is an authentication protocol that is an extension of OAuth 2.0. While OAuth 2.0 is only a framework for building authorization protocols and is mainly incomplete, OIDC is a full-fledged authentication and authorization protocol. OIDC also makes heavy use of the Json Web Token (JWT) set of standards. These standards define an identity token JSON format and ways to digitally sign and encrypt that data in a compact and web-friendly way.
There are really two types of use cases when using OIDC. The first is an application that asks the Keycloak server to authenticate a user for them. After a successful login, the application will receive an identity token and an access token. The identity token contains information about the user such as username, email, and other profile information. The access token is digitally signed by the realm and contains access information (like user role mappings) that the application can use to determine what resources the user is allowed to access on the application.
The second type of use cases is that of a client that wants to gain access to remote services. In this case, the client asks Keycloak to obtain an access token it can use to invoke on other remote services on behalf of the user. Keycloak authenticates the user then asks the user for consent to grant access to the client requesting it. The client then receives the access token. This access token is digitally signed by the realm. The client can make REST invocations on remote services using this access token. The REST service extracts the access token, verifies the signature of the token, then decides based on access information within the token whether or not to process the request.
SAML 2.0 is a similar specification to OIDC but a lot older and more mature. It has its roots in SOAP and the plethora of WS-* specifications so it tends to be a bit more verbose than OIDC. SAML 2.0 is primarily an authentication protocol that works by exchanging XML documents between the authentication server and the application. XML signatures and encryption is used to verify requests and responses.
There are really two types of use cases when using SAML. The first is an application that asks the Keycloak server to authenticate a user for them. After a successful login, the application will receive an XML document that contains something called a SAML assertion that specify various attributes about the user. This XML document is digitally signed by the realm and contains access information (like user role mappings) that the application can use to determine what resources the user is allowed to access on the application.
The second type of use cases is that of a client that wants to gain access to remote services. In this case, the client asks Keycloak to obtain an SAML assertion it can use to invoke on other remote services on behalf of the user.
How to get user information from KeyCloak server in Securing your Java Servlet Application with Keycloak ?
It is easy. In Servlet application, we add the following to the pom.xml:
<dependency>
<groupId>org.keycloak</groupId>
<artifactId>keycloak-core</artifactId>
<version>4.8.3.Final</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.keycloak</groupId>
<artifactId>keycloak-adapter-core</artifactId>
<version>4.8.3.Final</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.keycloak</groupId>
<artifactId>keycloak-adapter-spi</artifactId>
<version>4.8.3.Final</version>
<scope>provided</scope>
</dependency>
and in servlet code, we add following import
import org.keycloak.KeycloakPrincipal;
import org.keycloak.KeycloakSecurityContext;
import org.keycloak.TokenVerifier;
import org.keycloak.common.VerificationException;
import org.keycloak.representations.AccessToken;
import org.keycloak.representations.IDToken;
and the finally, we use keycloak api to get user information return from Keycloak server:
KeycloakPrincipal principal = (KeycloakPrincipal)request.getUserPrincipal();
String user = "no-name";
AccessToken accessToken = principal.getKeycloakSecurityContext().getToken();
user = accessToken.getPreferredUsername();
response.getWriter().println("Hello World! " + user);
Now, open web browser and type into address bar http://localhost:8081/SimpleServlet-1
then we go to login screen:
after success authentication, we see the result of keycloak client - server communication:
http://localhost:8081/SimpleServlet-1/hello
SSO with Keycloak is easy and effective. Other SSO open source framework is CAS but It is more difficult than Keycloak framework.
Reference Documents
https://www.keycloak.org/KeycloakServer
https://medium.com/@venkateshpnk22/single-sign-on-in-cas-server-with-java-spring-security-
78bd5c45ac29
https://github.com/apereo/cas-overlay-template/tree/5.1
https://apereo.github.io/cas/5.1.x/installation/Configuration-Properties.html
https://mkyong.com/tomcat/how-to-configure-tomcat-to-support-ssl-or-https/
0 comments:
Post a Comment