IBM Sterling
Hide about this portal


This portal is to open public enhancement requests for IBM Sterling products and services. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas

  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Add a new idea Subscribe
Status Future consideration
Workspace Sterling External Authentication Server
Categories Security
Created by Guest
Created on Jan 8, 2018

RELATED IDEAS

PIV Card Support for Sterling MFT/B2B Products

See this idea on ideas.ibm.com

PIV was initially introduced by HSPD-12 (Homeland Security Presidential Directive 12), in August of 2004. However, it is just now that agencies are being mandated to comply with this directive. The first required delivery date that we know of for this functionality is March 31, 2018, by DOL. However, CMS, VA, Treasury BFS, IRS, OPM and DOI have told us that they will also need the functionality sometime in 2018.
• The concept of PIV Cards was initially introduced to establish a "common identification standard" for Federal Employees and Contractors. See reference at the following link: http://www.dhs.gov/homeland-security-presidential-directive-12
• The following link contains references and links to all of the current HSPD-12 documents and requirements, which have apparently been changed over the years: http://www.idmanagement.gov/homeland-security-presidential-directive-12
• The PIV Card requirement is specifically referenced by the FIPS 201-2 standard from March of 2006 and last updated in August of 2013. The latest version is referenced at the following link: http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.201-2.pdf
• FIPS 201-2 requires Federal agencies to comply within 12 months of the last change date, which was 8/2013. However, that did not happen as we first started to hear about it from our Federal customers in 2015. In speaking with the DOI Team in 2015, they shared that PIV Cards are based on the Microsoft Smart Card Authentication Architecture, which is documented at the following link and includes a relationship diagram of the parts associated with the architecture: https://msdn.microsoft.com/en-us/library/windows/desktop/aa380142(v=vs.85).aspx
• The Microsoft Smart Card Authentication Architecture is based on the following PC/SC Workgroup standard: http://www.pcscworkgroup.com/specifications/overview.php

DOI explained that the PIV Card contains a userid and a certificate that are unique to each user. Here is the PIV Card workflow as it was explained to me:

1. The user inserts the PIV Card into a card reader that is attached to the workstation
2. The user presses the CTRL+ALT+DEL keys at the same time
3. Windows reads card and asks for a PIN
4. Once the correct PIN is entered, all of the information is validated. Validation is probably against AD/LDAP. However, the DOI folks on the call were not quite sure.
5. Once the user has been validated/authenticated and logs onto their workstation, they can access any applications that are enabled to use PIV Cards/AD/LDAP, without having to enter logon information because the logon information is apparently passed to the application from the initial logon to the workstation.

Since the PIV Card requirement is a DHS directive, this is something that we really need to incorporate into SEAS as quickly as possible, in order to handle the demand for this functionality, that is just starting and likely to increase in the near future.
DeveloperWorks ID DW_ID108051
RTC ID RTC_ID545630
Link to original RFE http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=108051
What is your industry? Government
  • Guest
    Reply
    |     Jan 17, 2018

    This initiative is also related to U.S. Department of Defense clients.

    Implementing CAC smart card authentication for Web Sites

     
     

    This blog discusses how to enable web sites to support access via the Department of Defense Common Access Card (CAC).

    What is a CAC?

    The Common Access Card  is a secure identification card issued to Department of Defense (DOD) personnel and civilian contractors.  It is a “Smart Card” in that it has an embedded chip which, along with a secret personal identification number (PIN) code, securely identifies the card holder.

    Web sites secured by CAC require the user to swipe the card through a card reader that is attached to their personal computer.  The user must also enter the PIN code before they can gain access to the web site.  There are many readers available, from many vendors.  Some readers are build into laptops, others attache via the USB port.

    How do web sites enable CAC authentication?

    Fortunately, your web site does not need to know the specifics about the CAC reader nor provide any drivers.  All this is taken care of by the end-user when they install their card reader.  Your web site only needs to enable X509 certificate-based authentication.  X509 certificates are files that prove that the user is who they claim to be.  The Common Access Card contains one (or more) of these certificates and presents it to your web site when the user tries to log in.

    Let’s talk a little bit about how X509 certificates work so we can understand what is needed to enable web sites.   This will be an oversimplification but we just want to know enough to configure our web site.  X509 user security needs two files.  Each user of your site needs an  X509 certificate file.  This file is issued to every user that needs one by a certificate authority.   In this case that authority is the United States Department of Defense.

    and the file comes to the user embedded on the CAC.  The DOD usually requires users to pass a security clearance before issuing the certificate.  Your company or organization cannot produce a CAC card or certificate but you can apply to the DOD for a test CAC here.

    The second file is the Certificate Authority (CA) file.  For CAC, this file comes from the DOD as a plain old file.  Actually it’s a set of files and you can get them here.  Please note that the DOD adds new Certificate Authority files from time to time so you will need to check this site and refresh periodically.  These CA files are installed on your web site and let your web site know that it can trust users with a Common Access Card.  It also tells your web site how to get the user’s browser to prompt for the card.  Configuring your web site to prompt for a CAC card is specific to the type of web site you are using.  Some examples include:

    This assumes that your web server is handing the Secure Sockets Layer (SSL) communications.  If instead, you are using a load balancer for SSL, consult the load balancer documentation on how to configure the DOD CAs.

    How to identify the user?

    It is not enough to trust users with Common Access Cards.  Millions of people have them and you probably won’t let them all into your site.  You need to identify who the user is and decide what to do with them.  It may be that you already have a list of authorized users, or you have will allow new users with CACs to auto-register.  In both cases, you need to identify the users.  This is accomplished with a special 10 digit identifier provided by the the Department of Defense called the Electronic Data Interchange Personal Identifier (EDIPI).  The EDIPI is a unique number assigned to each user that stays with them for life, even if they change their name or job title.  When a user swipes their CAC, this information is transmitted to your web application in the form of a common name (CN).  This common name will appear to your application as a http header variable, cookie, parameter or session variable depending on you implementation.  It takes the form: CN=LAST_NAME.FIRST_NAME.MIDDLE_NAME.0123456789.  Where the last part is the EDIPI.  It may be tempting to user the name portion, but remember that can change (e.g. person gets married).

    Once your application extracts the EDIPI, it needs to map it to your local directories user id.  This can be done

    by storing the EDIPI as a regular part of the user record during user creation/registration or you can add a special mapping database.

    Your application should then log the user in.  You may want to prompt for a password as part of the login.  Some DOD clients do not want a password prompt since the user already swiped the card and entered their secret PIN number.   In this case you may need to couple your CAC authentication system with single sign-on to provide access into your application.

    What about lost/stolen Cards?

    The DOD will insist that you not permit users to use lost/stolen/deactivated cards to access your web site.  For this purpose, the DOD issues a list of card’s serial numbers that have been revoked.  It is available here.  This Certificate Revocation List (CRL) must be checked and any certificate found on it should not be accepted. Be aware that this list is very long so your application may want to cache it.  Some web servers and load balancer can automatically check this list for you but may not perform adequately due to the length of the list.  Another option to frequently checking  and refreshing the CRL is to use a new protocol called Online Certificate Status Protocol (OCSP). OCSP allows your site to check an individual certificate to see if it has been revoked without loading and searching the entire list.  The address of the OCSP service (responder) is inside those certificate authority files that you previously downloaded.  One of the drawbacks of OCSP is that you need the service and connectivity to be up to perform the check. Your web site or load balance may be able to automatically perform OCSP.

    Special Considerations for Multiple Web sites

    If your web site really consists of multiple sites with multiple server (e.g. accounting.mysite.com and payments.mysite.com). Then each site must be protected from unauthorized access.  If you apply the CAC protection to each site, the users will be prompted for to swipe their card and enter their pin code each time they visit a different site.  This is secure not user friendly at all.  One mechanism to prevent this behavior is to implement CAC security on only one site, let’s call it the portal.  Then implement standard single sign-on (e.g. SAML) between the portal and all your other web sites. The user uses the CAC to access the portal and then single-sign on to move seamlessly from the portal to all the other web sites.  If the user should try to access one of your other sites first, bypassing the portal, the site will recognize the user is n

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.