It's all about Weblogic..!!!

September 9, 2011

Authentication..? Role Mapping..? Authorization..? Adjudication..?

Filed under: Security — streethawkz @ 7:25 pm

Authentication :

 

 

 

 

 

 

 

 

 

Subject (which thus far contained just the anonymous role and anonymous user) is modified according to the result of the authentication process, as follows :

If authentication is successful, then:

– The anonymous user is removed from the subject and replaced, as appropriate, by an authenticated user.

– Authenticated role is added.

– Other roles are added to the subject, as appropriate.

Notice that a successful authentication results then in a subject that has exactly

– one principal corresponding to a non-anonymous user,

– one principal corresponding to the authenticated role,

– and possibly other principals corresponding to enterprise or application roles.

If authentication is not successful, then the anonymous user is retained.

—————————————————————————————————————————-

  • What is a pricipal ?

Principal is an authenticated user or group.

  • What is a subject ?

Subject is a collection of principals.

Eg :

If a user is in 2 groups then the subject would be 1 + 2 = 3.

So the subject for the above example is 3.

We can conclude that subject = n + 1 principals, where n is the number of groups.

As soon as user gets authenticated we get a subject.

 

 

 

 

 

 

——————————————————————————————————————————

Role Mapper :

 

 

 

 

 

 

 

 

Consider an example where in “ weblogic “ user logs in to the console :

Resource IDs:

  • <Resource: type=<jndi>, application=, path={weblogic}, action=lookup>
  • <Resource: type=<url>, application=consoleapp, contextPath=/console, uri=/console.portal, httpMethod=GET>

input << JAAS Subject + resource id

output >>Role Set

  • <XACML RoleMapper getRoles(): returning roles Anonymous, Admin>

 

 

 

 

 

 

 

.

Authorization and Role Mapping :

– It takes the subject as input.

– Before authorization happens Role Mapping has to be done so that roles that a user belongs-to is know.

– The signed subject along with information as to what resource / page is being requested by a user is sent to the Role Mapper.

– The Role Mapper now checks the user role and passes the following information to the Authorizer :

1. Information about the Role of the user

2. The resource / page he is requesting

3. And the signed subject.

– Now authorizer uses these information and locates the resource and answers the “is access allowed?” question.

 

 

 

 

 

.

Authorization :

 

 

 

 

 

 

 

 

Check the Subject against deployment descriptor :

————————————————

In weblogic 9.1 and above two authorizers are enabled by default :

– DefaultAuthorizer

– XACML Authorization provider ( this is the default from WLS 9.1 and above )

—————————————————————————————————————————————-

Adjudication :

 

 

 

 

 

 

 

 

The WebLogic Adjudication provider has an attribute called Require Unanimous Permit that governs its behavior. By default, the Require Unanimous Permit attribute is set to TRUE, which causes the WebLogic Adjudication provider to act as follows:

  • If all the Authorization providers’ Access Decisions return PERMIT, then return a final verdict of TRUE (that is, permit access to the WebLogic resource).
  • If some Authorization providers’ Access Decisions return PERMIT and others return ABSTAIN, then return a final verdict of FALSE (that is, deny access to the WebLogic resource).
  • If any of the Authorization providers’ Access Decisions return ABSTAIN or DENY, then return a final verdict of FALSE (that is, deny access to the WebLogic resource).

If you change the Require Unanimous Permit attribute to FALSE, the WebLogic Adjudication provider acts as follows:

  • If all the Authorization providers’ Access Decisions return PERMIT, then return a final verdict of TRUE (that is, permit access to the WebLogic resource).
  • If some Authorization providers’ Access Decisions return PERMIT and others return ABSTAIN, then return a final verdict of TRUE (that is, permit access to the WebLogic resource).
  • If any of the Authorization providers’ Access Decisions return DENY, then return a final verdict of FALSE (that is, deny access to the WebLogic resource).
———————————————————————————————————————–

WebLogic Security Service supports the following types of security providers :

  •  Authentication :

It validates the username and password against a database and authenticates it.

It is mainly in clear text format – a username and password.

  • Identity Assertion :

Here the input is anything other than a username and password that is provided to authenticate a user. For example like a certificate or may be a face recognition/ fingerprint recognition where in the authentication is done based on pattern matching. ( this example is just to understand the concept of IA ).

So basically the authentication and the Identity Assertion do the same job – i.e authenticating a user.

The only difference is in the input format they accept.

  • Credential Mapping :

Credential mappings let you map WebLogic Server users to remote users.

It does the exact opposite job of an Identity Assertor.

It takes the authenticated user information and converts it into other formats.

Eg : x509 certificate format

  • Certificate Lookup and Validation (CLV) :

It mainly checks the chaining of certificates.

It also validates incoming certificates.

  • Auditor :

Logs all the events generated by other providers.

————————————————————————————————————————-

Advertisements

January 15, 2011

Steps to configure SAML 2 on Weblogic Server 10.3.0

Filed under: Security — streethawkz @ 12:56 pm

 

To setup SAML 2 with Weblogic 10.3.0 we need to create a security database even before creating domain.

Steps to use a pointbase database provided with Weblogic Installation :

  • Copy ” pbembedded.lic ” located in ” C:\bea10.3\wlserver_10.3\common\eval\pointbase\lib ” to ” C:\bea10.3\wlserver_10.3\common\eval\pointbase\tools “
  • We need to create two security database – one for the source side domain and another for the destination end domain.
  • Now start the PointBase server ( run ” startPointBase.cmd ” located in ” C:\bea10.3\wlserver_10.3\common\eval\pointbase\tools “
  • Start the PointBase console  ( run ” startPointBaseConsole.cmd ” located in ” C:\bea10.3\wlserver_10.3\common\eval\pointbase\tools “Login using the user name ” EXAMPLES ” and password ” EXAMPLES “, as shown below :

 

 

 

 

 

 

 

  • Now lets create a database table using the sample ” rdbms_security_store_pointbase.sql ” located in ” C:\bea10.3\wlserver_10.3\server\lib “

 

 

 

 

 

 

 

 

 

 

 

 

 

  • Now we need to create another database using the user name ” PUBLIC ” and password ” PUBLIC “

 

 

 

 

 

 

 

 

 

 

 

 

 

We have successfully created two security database, lets create the domains now, namely :

saml_2_source_post – Admin Server running on 7001 ( http ) and 7002 ( https )
saml_2_destination_post – Admin Server running on 7003 ( http ) and 7004 ( https )

  • Run the ” Configuration Wizard ” On the ” Customize Environment and Services Settings ” screen select the option ” Yes “

 

 

 

 

 

 

 

  • Select the option “I want to create, change, or remove RDBMS support” and make the changes as shown in the figure below, and also click on ” Test Connection ” button to make sure that the database is configured properly.

 

 

 

 

 

 

 

 

  • Configure SSL on both the domians, below is a link which talks about configuring ” Custom Identity and Custom Trust ” :

Link : http://wls4mscratch.wordpress.com/2010/06/08/steps-to-configure-custom-identity-custom-trust-on-wls/

 

SAML Souce site configuration :

  • We need to configure ” Credential Mapper ” on the IDP end.
  • So to ” myrealm ” –> ” Providers ” –> ” Credential Mapping ” –> and add a ” SAML2CredentialMapper ” say ” SAML2_CredentialMapper ” as shown below :

 

 

 

 

 

 

 

Now click on the newly created SAML2CredentialMapper say ” SAML2_CredentialMapper ” and make the following changes :

  • Issuer URI : http://www.souresite.com/saml
  • Name Qualifier : sourcesite.com
  • Web Service Assertion Signing Key Alias : cooldragon
  • Web Service Assertion Signing Key Pass Phrase : **********
  • Please type again To confirm : *********

 

 

 

 

 

 

 

 

Click on ” Servers ” –> Admin Server –> ” Federation Services ” –> ” SAML 2.0 Identity Provider ” and make the following changes :

  • Enabled : check
  • Only Accept Signed Authentication Request : check
  • Preferred Binding : POST


 

 

 

 

 

 

 

 

 

  • Click on ” Servers ” –> Admin Server –> ” Federation Services ” –> ” SAML 2.0 General ” and make the following changes :

Replicated Cache Enabled – Uncheck

Contact Person Given Name

Contact Person Surname

Contact Person Type

Contact Person Company

Contact Person Telephone Number

Contact Person Email Address

Organization Name

Organization URL

Published Site URL : http://<SourceSiteDNSName&gt;:<PORT>/saml2

Entity ID : ( Source Domain name)

Single Sign-on Signing Key Alias

Single Sign-on Signing Key Pass Phrase

Confirm Single Sign-on Signing Key Pass Phrase


 

 

 

 

 

 

 

 

 

 

 

 

 

 

  • Save the changes and export the IDP metadata into a XML file –> Click on “ Publish Meta Data ” button. ( say idp_metadata.xml ). We need to copy this file to the destination domain later.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Destination Site Configuration :

 

Now we need to generate the SAML destination site ( SP ) metadata

  • Click on ” myrealm ” –> ” Providers ” –> ” Authentication ” –> new ” SAML2IdentityAsserter “ say ” SAML2_IdentityAsserter :


 

 

 

 

 

Click on ” Servers ” –> Admin Server –> ” Federation Services ” –> ” SAML 2.0 Service Provider ” and make the following changes :

  • Enabled : check
  • Always Sign Authentication Requests : check
  • Force Authentication : Check
  • Preferred Binding : POST
  • Default URL : http://<DestinationSiteDNSName>:<PORT>/samldest01App

 

 

 

 

 

 

 

  • Now click on ” Servers ” –> Admin Server –> ” Federation Services ” –> ” SAML 2.0 General ” and make the following changes :

Replicated Cache Enabled : Uncheck

Contact Person Given Name

Contact Person Surname

Contact Person Type

Contact Person Company

Contact Person Telephone Number

Contact Person Email Address

Organization Name

Organization URL

Published Site URL : http://<DestinationSiteDNSName&gt;:<PORT>/saml2

Entity ID : ( Destination Domain name)

Single Sign-on Signing Key Alias

Single Sign-on Signing Key Pass Phrase

Confirm Single Sign-on Signing Key Pass Phrase

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  • Save the changes and export the IDP metadata into a XML file –> Click on “ Publish Meta Data ” button. ( say SP_metadata.xml ). We need to copy this file to the Source domain later.

 

 

 

 

 

 

  • Copy service provider metadata ( SP_metadata.xml ) to Source Domain and identity provider metadata ( idp_metadata.xml ) to the destination Domain as shown below :

 

 

 

 

 

 

  • Now configure Service Provider metadata on SAML Identity Provider in Source Site :
  • Log in to the source site Admin Console and click on ” Security Realms ” –> ” myrealm ” –> ” Providers ” –> ” Credential Mapper ”  –> ” SAML2_CredentialMapper ” –> ” Management ” –> ” New ” –> ” New Web Single Sign-On Service Provider Partner ” :











  • Name this “New Web Single Sign-On Service Provider Partner” as “SAML_SSO_SP01” and select the SP_metadata.xml file.


 

 

 

 

 

 

 

  • Click on the newly created ” SAML_SSO_SP01 ” and enter the following :

Name :  SAML_SSO_SP01

Enabled :  Checked

Description  : SAML_SSO_SP01

Key Info Included  : Check

 

 

 

 

 

 

 

Click on Site info and verify the data :

 

 

 

 

 

 

 

  • Now configure Identity Provider metadata on SAML Service Provider in Destination site :

Login to Destination Site Admin Console :

Click on ” Security Realms ” –> ” myrealm ” –> ” Providers ” –> ” Credential Mapper ” –> SAML2_IdentityAsserter –> ” Management ”                           –> ” New ” –> ” New Web Single Sign-On Identity Provider Partner ” say ” SAML_SSO_IDP01 ”  and then select ” idp_metadata.xml ” :

 

 

 

 

 

 

 

 

 

 

 

 

  • Click on ” SAML_SSO_IDP01 ” and enter the following :
Name : SAML_SSO_IDP01
Enabled : Check
Description : SAML_SSO_IDP01
Redirect URIs : /samldest01App/restricted01/samldest01services.jsp

 

 

 

 

 

 

 

  • Deploy the source and destination application
  • Ufff..!! the configuration is now complete 🙂 Test your SAML SSO now.

Steps to generate self signed certificates using keytool

Filed under: Security — streethawkz @ 1:43 am

Below are the commands we need to run to generate self signed certificates :

  • keytool -genkey -alias cooldragon -keyalg RSA -keypass privatepassword -keystore identity.jks -storepass password ( create a key pair )

 

 

 

 

 

 

 

  • keytool -export -alias cooldragon -file root.cer -keystore identity.jks ( export the certificate from identity keystore into a file, say root.cer)

     

     

     

     

     

     

     

    • keytool -import -alias cooldragon -trustcacerts -file root.cer -keystore trust.jks ( import the certificate you exported into trust.jks )

       

       

       

       

       

       

       

      • We can list the certificates present in the identity.jks using the following command :

        keytool -list -v -keystore  identity.jks -storepass password

         

         

         

         

         

         

         

        • Now lets view the file that was exported from the identity.jks ( i.e root.cer )

          keytool -printcert -file root.cer

           

           

           

           

           

           

           

          • To list the contents of trust.jks use the following command :

            keytool -list -v -keystore trust.jks -storepass password

            January 14, 2011

            Steps to configure SAML 1.1 on Weblogic 9.2.x or 10.0.x

            Filed under: Security — streethawkz @ 11:11 pm

            Below are the steps to configure SAML 1.1 on Weblogic 9.2.4 :

            In the example below :

            – I have setup two domains namely,

            1. Source Domain — >  saml_1.1_source_post

            2. Destination Domain –>  saml_1.1_destination_post

            Then setup SSL ( Custom Identity and Custom Trust ) on both domains for Admin  server as shown in the link below :

            Link :

            On Source Domain the Admin Server is running on port 7001 ( http ) and 7002 ( https ).

            On Destination Domain the Admin Server is running on port 7003 ( http ) and 7004 ( https ).

            SAML Source Site configuration :

            • Login to the Admin Console –> ” Security Realms ” –> ” myrealm ” –> ” Providers ” –> ” Credential Mapping ” –> Now add a ” SAMLCredentialMapperV2 ” as shown in the fig below ( say ” SAML_CredentialMapper ” ) :

             

             

             

             

             

             

             

            • Now select ” SAML_CredentialMapper ” and click on ” Provider Specific ” tab and enter the following ( as shown in fig below ) :

              Signing Key Alias : cooldragon

              Name Qualifier :  saml_source

              Signing Key Pass Phrase : ********

              Confirm Signing Key Pass : ********

              Issuer URI : http://www.oracle.com/saml

               

               

               

               

               

               

               

              * Restart the Server now

              • Click on ” Security Realms ” –> ” myrealm ” –> ” Providers ” –> ” Credential Mapping ” –> ” SAML_CredentialMapper ” –> ” Management ”     –> create new ” Relying Party ” ( say ” rp_00001 ” ) and select profile ” Browse/Post “

               

              • Now click on ” rp_00001 ” and enter the following :

              Enabled : check

              Target URL : https://localhost:7004/samldest01App/restricted01/samldest01services.jsp ( Destination site URL for which authentication is required )

              Assertion Consumer URL : https://localhost:7004/samlacs/acs ( URL at which an assertion consumer service ( acs ) for this SAML relying party can be reached )

              Assertion Consumer Parameter : APID=ap_00001 ( Optional query parameters that will be added to acs url when redirecting to destination url )

              Sign Assertions : check

              Include Keyinfo : check

              Include Groups Attribute : check

               

               

               

               

               

               

               

              • Click on ” Security Realms ” –> ” myrealm ” –> ” Providers ” –> ” Credential Mapping ” –> ” SAML_CredentialMapper ” –> ” Management ”       –> ” Certificates ” :

                Alias : cooldragon

                Certificate File Name : root.cer

                 

                 

                 

                 

                 

                 

                • Now click on ” Servers ” –> ” AdminServer ” –> ” Federation Services ” –> ” SAML 1.1 Source Site ” and enter the following :

                  Source Site Enabled : check

                  Source Site URL  : https://localhost:7002/samlsourceApp ( url for source site )

                  Signing Key Alias : cooldragon

                  Signing Key Passphrase : *******

                  Intersite Transfer URIS : /samlits_cc/its ( donot change anythin here – leave it as it is (default) )

                  ITS Requires SSL : check

                  Assertion Retrieval URIs : /samlars/ars ( URIs on which to listen for incoming assertion retrieval requests )

                  ARS Requires SSL : check

                   

                   

                   

                   

                   

                   

                   

                  * Restart server now

                  SAML Destination Site Configuration :

                  Login to Admin Console on the destination domain and click on ” Security Realms ”  –> ” myrealm ”  –> ” Providers ” –> ” Authentication ”  –> and create a new ” Authentication Provider ” ( say ” SAML_IdentityAsserter ” ) of type ” SAMLIdentityAsserterV2 ”

                   

                   

                   

                   

                   

                   

                   

                  * Restart your server

                  • Click on ” Security Realms ”  –> ” myrealm ”  –> ” Providers ” –> ” Authentication ” –>  ” SAML_IdentityAsserter ” –> ” Management ”              –> ” Certificates “

                  Alias : cooldragon

                  Certificate File Name : root.cer

                  • Click on ” Security Realms ”  –> ” myrealm ”  –> ” Providers ” –> ” Authentication ” –>  ” SAML_IdentityAsserter ” –> ” Management ”                –> ” Asserting Parties ” –> create a new SAML Asserting Party ( say ” ap_00001 ” ) of type ” Browse/Post “

                   

                   

                   

                   

                   

                   

                  • Now click on ” ap_00001 ” and fill in the following :

                    Enabled : check

                    Target URL :  https://localhost:7002/samlsourceApp ( url of this saml asserting party )

                    POST Signing Certificate alias : cooldragon

                    Source Site Redirect URIs :  /samldest01App/restricted01/samldest01services.jsp ( optional set of URIs from which unauthenticated users will be redirected to the configured ITS url. If this is set Intersite Transfer url must also be set. )

                    Source Site ITS URL :  https://localhost:7002/samlits_ba/its ( ITS url for saml source site for this asserting party )

                    Source Site ITS Parameters RPID= rp_00001 ( optional query parameter that will be added to ITS url when redirecting to source site )

                    Issuer URI : http://www.oracle.com/saml ( Issuer URI for saml authority for issuing assertions for this saml asserting party )

                    Signature Required : check

                    Asserting Signing Certificate Alias : cooldragon

                    Process Groups Attribute : check

                     

                     

                     

                     

                     

                     

                     

                     

                    • Now click on ” Servers ” –> ” AdminServer ” –> ” Federation Services ” –> ” SAML 1.1 Destination Site ” and enter the following :

                      Destination Site Enabled : check

                      Assertion Consumer URIs : /samlacs/acs

                      ACS Requires SSL : check

                      SSL Client Identity Alias : cooldragon

                      SSL Client Identity Pass Phrase : ********

                      POST Recipient Check Enabled : check

                      POST one Use Check Enabled : check

                      Used Assertion Cache Properties APID = ap_00001

                       

                       

                       

                       

                       

                       

                       

                      Your SAML 1.1 is now configured 🙂 Deploy source and destination applications and verify if SSO is working fine.

                        Blog at WordPress.com.