PHP / Java Integration

Posted by Unknown on Tuesday, January 11, 2011

More about → PHP / Java Integration

Lightweight Directory Access Protocol PHP

Posted by Unknown

  • Introduction

  • Installing/Configuring

  • Predefined Constants

  • Using the PHP LDAP calls

  • Examples

  • LDAP Functions



  • More Here


    Courtesy:http://php.net/manual/en/book.ldap.php
    More about → Lightweight Directory Access Protocol PHP

    Mod_auth_kerb Apache

    Posted by Unknown

    Mod_auth_kerb is an Apache module designed to provide Kerberos authentication to the Apache web server. Using the Basic Auth mechanism, it retrieves a username/password pair from the browser and checks them against a Kerberos server as set up by your particular organization. The module also supports the Negotiate authentication method, which performs full Kerberos authentication based on ticket exchanges, and does not require users to insert their passwords to the browser. In order to use the Negotiate method you need a browser supporting it (currently standard IE6.0 or Mozilla with the negotiateauth extension).


    The module supports both kerberos4 and kerberos5 protocols for password verification. The Negotiate mechanism can be only used with Kerberos v5. The module supports both 1.x and 2.x versions of Apache.




    Configuration


    This page describes configuration of module version 5.0. Configuration guide for the older module 4.x can be found here.


    Before starting configuring the module make sure your Kerberos enviroment is properly configured (i.e. KDC, /etc/krb5.conf, etc.). The easiest way to check is using the kinit command from the apache machine to get a ticket for some known principal (preferably that one who will be used to test the module).


    Now you have to create an service key for the module, which is needed to perform client authentication. Verification of the kerberos password has two steps. In the first one the KDC is contacted using the password trying to receive a ticket for the client. After this ticket is sucessfuly acquired, the module must also verify that KDC hasn't been deliberately faked and the ticket just received can be trusted. If this check would haven't been done any attacker capable of spoofing the KDC could impersonate any principal registered with the KDC. In order to do this check the apache module must verify that the KDC knows its service key, which the apache shares with the KDC. This service key must be created during configuration the module. This service key is also needed when the Negotiate method is used. In this case the module acts as a standard kerberos service (similarly to e.g. kerberized ssh or ftp servers). Default name of the service key is HTTP/@REALM, another name of the first instance can be set using the KrbServiceName option. The key must be stored in a keytab on a local disk, the Krb5Keytab and Krb4Srvtab options are used to specify the filename with the keytab. This file should be only readable for the apache process and contain only the key used for www authentication.


    In order to get the module loaded on start of apache add following line to your httpd.conf:


    LoadModule auth_kerb_module libexec/mod_auth_kerb.so


    Summary of Supported Directives
    AuthType type


    For Kerberos authentication to work, AuthType must be set to


    *


    Kerberos


    For the reasons of backwards compatibility the values KerberosV4 and KerberosV5 are also supported. Their use is not recommended though, for finer setting use following three options.




    KrbMethodNegotiate on | off


    (set to on by default)


    To enable or disable the use of the Negotiate method. You need a special support on the browser side to support this mechanism.


    KrbMethodK5Passwd on | off


    (set to on by default)



    To enable or disable the use of password based authentication for Kerberos v5.


    KrbMethodK4Passwd on | off


    (set to on by default)


    To enable or disable the use of password based authentication for Kerberos v4.


    KrbAuthoritative on | off


    (set to on by default)


    If set to off this directive allow authentication controls to be pass on to another modules. Use only if you really know what you are doing.


    KrbAuthRealms realm1 [realm2 ... realmN]


    This option takes one or more arguments (separated by spaces), specifying the Kerberos realm(s) to be used for authentication. This defaults to the default realm taken from the local Kerberos configuration.


    KrbVerifyKDC on | off


    (set to on by default)


    This option can be used to disable the verification tickets against local keytab to prevent KDC spoofing atacks. It should be used only for testing purposes. You have been warned.


    KrbServiceName service


    (set to HTTP by default)


    For specification the service name that will be used by Apache for authentication. Corresponding key of this name must be stored in the keytab.


    Krb4Srvtab /path/to/srvtab


    This option takes one argument, specifying the path to the Kerberos V4 srvtab. It will simply use the "default srvtab" from Kerberos V4's configuration if this option is not specified. The srvtab must be readable for the apache process, and should be different from srvtabs containing keys for other services.

    More Here


    Courtesy:http://modauthkerb.sourceforge.net/configure.html
    More about → Mod_auth_kerb Apache

    OpenSSO and Secure Ticket Service (STS)

    Posted by Unknown

    The setup involves a Liferay Portal that authenticates the users using OpenSSO Express 8. The portlets make SOAP calls to a JBoss 5.1 server that has some EJB’s exposed as a web service provider.
    The principle behind STS is really simple. You don’t have to change your webservice provider, client or WSDL. Just plug the right client and server handler, configure OpenSSO and go!
    On the SUN Development Blog there is an excellent walk through named Enabling Web Service Security with OpenSSO WSS Agent. This post is about our experience with this setup and the pitfalls we encountered.

    Getting WSSAgents.zip – Thank you Oracle

    OpenSSO integrates the STS client and provider using JAX-WS client- and server-handlers. These are contained in WSSAgents.zip, which was provided at http://opensso.dev.java.net
    Oracle removed most of the downloads from the OpenSSO site after completing the SUN merger. Fortunately a new company called ForgeRock took the OpenSSO source code and will continue its development of under the OpenAM name. They provide downloads and source code for OpenAM Express 9. Currently a nightly build of WSSAgents.zip is provided; however a stable OpenAM Express 9 build isn’t.
    I decided to build OpenAM Express 9 on my one.
    Big mistake; it took me more than half a day. First of all you need to download and compile a lot of dependencies. Next steps involved building the components using several ant scripts and commands. Since no real documentation exists, this was a trial and error effort. I sure hope the build gets mavenized soon!
    But let me save you this little inconvenience: OpenSSO Express 9 WSSAgents.zip

    @ClientHandler and Tomcat


    Configuring OpenSSO and the JBoss Webservice Provider worked like a charm, but we couldn’t get the ClientHandler to work. We tried both using ws-import and adding @ClientHandler to the client ourselves.
    Since Tomcat is not a full JEE container, it doesn’t support JSR 109 service endpoints and thus no fancy @ClientHandler annotations. We solved this by adding the client handler in our factory class:
    public ServiceFactory(String wsdlLocation) {
    service = new ServiceImpl(wsdlUrl, new QName(TARGET_NAMESPACE, LOCAL_PART_SERVICE_IMPL));
    service.setHandlerResolver(new STSHandlerResolver());
    }


    private class STSHandlerResolver implements HandlerResolver {
    public List getHandlerChain(PortInfo portInfo) {
    List handlerChain = new ArrayList();
    handlerChain.add(new com.sun.identity.wssagents.jaxws.client.ClientHandler());
    return handlerChain;
    }
    }

    Encoding

    Our OpenSSO setup uses url-encoding for the iPlanetDirectoryPro cookie. Without it, tomcat will give up on the = character. The openssoclientsdk doesn’t like this. It only supports unencoded cookies or c66encoded cookies. c66 encoding is an OpenSSO specific url encoding. The cookie contains the site the web service client has to connect to get the STS Ticket. If the cookie can’t be decoded, the connection url will be empty.
    You’ll have to enable the com.iplanet.am.cookie.c66encode property in the OpenSSO console to fix this.

    SOAP 1.2

    Next up: what SOAP are you using? The STS Client Handler only supports SOAP 1.2, but the JAX-WS default is SOAP 1.1.
    Generating a WSDL for 1.2 isn;t that hard though, unless you’re using JBoss & Metro. Due to a bug JBoss won’t generate SOAP 1.2 WSDL’s. We used the wsgen goal of the jaxws-maven-plugin to generate SOAP 1.2 and make sure to set extension=true on to create the correct WSDL while building the provider.
    At the client side the wsimport goal should generate the right code, but only with extension=true
    Now you should have a working SOAP 1.2 – STS setup, unless…

    Sync you clocks

    When generating a STS Ticket, OpenSSO will check the clock difference between the STS web service client and the OpenSSO instance. A maximum of 5 seconds is allowed. If the difference is bigger and you cannot change (one of) the clocks, you can adjust it by setting the com.sun.identity.wss.security.timeskew property in the OpenSSO console to something bigger (3600000 in our case). This isn’t recommended for production environments of course…

    More Here


    Courtesy:http://blog.iprofs.nl/2010/04/29/opensso-and-secure-ticket-service-sts/
    More about → OpenSSO and Secure Ticket Service (STS)

    Integrate DNN with ADFS without writing a new Authentication Provider

    Posted by Unknown

    The partner organization already had ADFS setup. The goal was to have the partner organization authenticate the user and then have DNN automatically recognize the user, not having to enter any more credentials. From there we wanted to manage the groups and permissions through the regular DNN portal.
    I was initially under the misconception that I could not use the current DNNMembershipProvider and I would have to create a whole new Authentication Provider and collect the credentials and pass them to my partner organization.



    What I have figured out is that you CAN use the existing DNNMembership provider, but you have to create the user before the request gets to the DNNMembership provider using the information provided by ADFS.


    Note: This method is a straight pass-through from ADFS to DNN. No measures are taken to authenticate the user or to check any of the inputs from ADFS.


    As an aside, this method works not only with ADFS but also any other external 3rd-party Authentication method that sends user information in headers or cookies. Change the context_AuthenticateRequest method to suit your requirements.


    Here are the pre-conditions to this article. I expect:



    * Your partner organization has ADFS up and running
    * You have your ADFS proxy up and running and it talks to the partner organization.
    * ADFS Web Agent is installed on the server you are running.


    Let’s get started.
    HTTPModule


    What you have to do is create an HTTPModule that will intercept the AuthorizeRequest events before DNN does. An over-simplified definition of an HTTPModule is, it is a piece of code that runs before any page gets hit. You can listen for a lot of different events. For more information, click here.


    To create the HTTPModule you will need to:


    * Open Visual Studio and create a new class library.
    * Create a new class and copy the code attached to this blog.
    *
    Add References to the following DLLs
    o DotNetNuke
    o System.Web
    o System.Web.Security.SingleSignOn
    o System.Web.Security.SingleSignOn.ClaimsTransform
    o System.Web.Security.SingleSignOn.Permissions
    * Compile the solution
    * The DLL that is created will need to be placed in the bin directory of your website.
    * Make changes to your web.config (explained in a later section).


    I will walk through a bit of the code. Here is the first snippet of code. We start listening for the AuthenticateRequest event. All other events pass through untouched.
    view source
    print?
    1 public void Init(HttpApplication context)
    2 {
    3 //Start listening for each authentication request
    4 context.AuthenticateRequest += new EventHandler(context_AuthenticateRequest);
    5 }


    Now, what do we do when this event is fired off? To shorten the namespace I added the statement
    view source
    print?
    1 using SSO = System.Web.Security.SingleSignOn;


    First off, we need to get the information that ADFS has sent us by casting the User.Identity into the ADFS object SingleSignOnIdentity.
    view source
    print?
    1 public void context_AuthenticateRequest(object sender, EventArgs e)
    2 {
    3 HttpApplication app = (HttpApplication)sender;
    4 //By the time the request gets to here, it should have been authenticated
    5 //against ADFS.
    6 SSO.SingleSignOnIdentity id = (SSO.SingleSignOnIdentity)app.User.Identity;


    At this point you will have access to the user’s Identity and any claims coming from the ADFS server. You can access them through id.SecurityPropertyCollection. You can use them to populate the new user account. You can iterate through the claims with the following code
    view source
    print?
    1 foreach(SecurityProperty sp in id.SecurityPropertyCollection)
    2 {
    3 Console.WriteLine(sp.Name);
    4 Console.WriteLine(sp.Value);
    5 }


    Next, we check to see if the use already exists in the database by using the DNN API function GetUserByName. If it doesn’t, then the user is created by the standard DNN API function CreateUser and logged in. If the user does exist already then we log them in automatically. The user will automatically be added to the Registered Users and Subscribers security groups.
    view source
    print?
    01 //'See if user exists in DNN Portal user DB
    02 UserInfo objUserInfo = UserController.GetUserByName(currentPortal.PortalId, id.Name);
    03 //' user does exist - try to create on the fly
    04 if (objUserInfo == null)
    05 {
    06 objUserInfo = new UserInfo();
    07 objUserInfo.DisplayName = id.Name;
    08 objUserInfo.FirstName = id.Name;
    09 objUserInfo.LastName = id.Name;
    10 objUserInfo.Username = id.Name;
    11 objUserInfo.Membership.Password = "AReallyStrongPassword";
    12 objUserInfo.PortalID = currentPortal.PortalId;
    13 objUserInfo.Email = id.Name;
    14 UserCreateStatus objUserCreateStatus = UserController.CreateUser(ref objUserInfo);
    15 //See if the user was added successfully
    16 if (objUserCreateStatus == UserCreateStatus.Success)
    17 {
    18 //We have created them successfully, so let them into the site
    19 LetsLogUserIn(objUserInfo);
    20 }
    21 else
    22 {
    23 //This will send the error to the error log, but the user will experience an infinite loop
    24 throw new Exception("User not created successfully: " + objUserInfo.Username + "- " + objUserCreateStatus.ToString());
    25 }


    Here is the LetsLogUserIn function:
    view source
    print?
    01 private void LetsLogUserIn(UserInfo objUserInfo)
    02 {
    03 try
    04 {
    05 //Get the current portal
    06 PortalSettings currentPortal = PortalController.GetCurrentPortalSettings();
    07 //set the language to the default language of the portal
    08 Localization.SetLanguage(currentPortal.DefaultLanguage);
    09 //Log the user in
    10 UserController.UserLogin(currentPortal.PortalId,
    11 objUserInfo,
    12 currentPortal.PortalName,
    13 HttpContext.Current.Request.UserHostAddress,
    14 false);
    15 }
    16 catch(Exception ex)
    17 {
    18 Exceptions.LogException(ex);
    19 }
    20 }
    Web.Config


    We need to make several changes to the web.config. First we need to make the changes necessary for ADFS and then we need to make changes for our HTTPModule.


    The ADFS changes are the standard web.config changes you would do for any ADFS claims-aware site. You first need to add the section groups to your web.config.
    view source
    print?
    1
    2

    3


    Then you need to add the actual section. The needs to be EXACTLY what is put into ADFS. Remember, this URL needs to have a / at the end to prevent ADFS from posting to a directory listing. The element needs to be changed to reflect the name of your server.
    view source
    print?
    01
    02 …
    03
    04
    05 55
    06
    07 https://your_application/
    08
    09 https://fs-server/adfs/fs/federationserverservice.asmx
    10
    11 …
    12


    If you would like to have logging (and who doesn’t like loggingJ) you will need to add the following section at the end of your web.config

    More Here


    Courtesy:http://binnington.wordpress.com/
    More about → Integrate DNN with ADFS without writing a new Authentication Provider