Code your Own: Authentication Provider for Blackboard Learn


Published on

Presentation from Blackboard Developers Conference 2012 on how to build your own Authentication plugin for Blackboard Learn 9.1 Service Pack 8 or later.

Published in: Technology
1 Like
  • @dan2bit This is weird, I didn't receive a notification of your comment. Sorry, its's been a while.

    Your answer is most appreciated. Thanks for taking the time to respond; It clarified a lot my doubts. I'm thinking on creating a b2 to make things possible.
    Are you sure you want to  Yes  No
    Your message goes here
  • From the Learn side, Shibboleth is a 'fully delegated provider' as described on slide #6 - that means the user leaves the Learn context to login in on a page on the Shibboleth provider. LDAP is a 'delegated credential provider' as described on slide #5 - that means the user's credentials are entered on the Learn login page and passed to the LDAP server for validation. So the only providers that can be 'chained' using the provider order tool are credential providers, since those are the only ones where the Learn user enters their credentials on the Learn page.

    A couple untested alternatives to explore:
    * You could configure your Shibboleth provider to fall back to your LDAP server itself - that configuration would be managed in your Shibboleth setup, and Learn would just send your users to the Shibboleth server
    * Alternatively, you could provide both a login/password form and a link to Shibboleth on your login page, and help users select which to use by means of some text on page customization of your login page, or some IP address segregation you configure in your provider setup - for example, allowing users on your school's subnet to log in via LDAP but requiring outsiders to use Shib. These customizations can be configured on the Learn side if needed.
    * It might be possible to build a custom B2 that queries Shibboleth as though it were a delegated credential provider, and then if that fails, queries the LDAP server, but that would require some kind of API or service on the Shibboleth side that has access to the nternals of how Shibboleth authenticates users, for the Learn B2 to call. I'm not familiar enough with Shibboleth to know if it has such an API or service.

    Hope this helps,
    Are you sure you want to  Yes  No
    Your message goes here
  • Hi Dan,

    Would it be possible code a b2 which uses Shibboleth as main authentication provider and LDAP as fallback?

    I've seen the option 'Provider Order' but I couldn't include/mark Shibboleth. I assume that's the way it should work because the only auth providers available to order are LDAP and LearnInternal.

    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Agenda for the presentation.
  • Password transmission is hashed regardless of SSL encryption of the whole HTTP requestGetting the user credentials INTO Learn can be accomplished in a number of ways – go check out Jim Riecken’s presentation after this one
  • This is your LDAP/Active Directory/Atlassian Crowd modelThe “thumbs up” is received by Learn from the credential provider and the user is granted access (or not)
  • This is your CAS, Shibboleth or OpenID modelAs with the prior model, the remote server vouches for the user
  • Went from back end config file incantation with service restart prior to verification, to GUI-enabled real-time configuration, testing, enabling and chainingSimilar in many ways to the transition from banging on an old IBM typewriter, busting out the whiteout or starting completely over when you found a typo.To our modern word processor experience where you can move and make corrections with (relative) ease.You still have to get the writing right – you still have to successfully connect and properly configure, and your user data still has to be useful in both Learn and in the provider
  • Went from back end config file incantation with service restart prior to verification, to GUI-enabled real-time configuration, testing, enabling and chainingSimilar in many ways to the transition from banging on an old IBM typewriter, busting out the whiteout or starting completely over when you found a typo.To our modern word processor experience where you can move and make corrections with (relative) ease.You still have to get the writing right – you still have to successfully connect and properly configure, and your user data still has to be useful in both Learn and in the provider
  • Multiple fully delegated providers can be “lined up” on one login pageDelegated or credential providers can be restricted to only particular login hostnamesDifferent custom login pages can be built for different hostnames (requires Community license)
  • All login attempts, successful logins, logouts and session expirations are recorded in a dedicated log file in the logs directory of the application server, as well as in a database table that supports the searching & filtering UI shown here. The database table is purged periodically by a database job, and can also be purged manually from this UI.
  • Because so many configuration options are available now from the User Interface, we needed to design a fallback mechanism to allow an administrator to access the system regardless of it’s current configuration state – the solution is the command-line emergency login URL generator.It requires back-end access (or a Managed Hosting ticket), and generates a one-time-use URL with an expiration time, allowing access to the system to revert any broken configuration.
  • Apache 2 is supported, but doesn’t ship inside the SP8 installer. Once Learn is installed, you can configure your instance to point to an Apache 2 serverCentral Authentication Service – originally built by Yale and supported by Jasig (Java in Administration Special Interest Group) since 2004LDAP – lightweight directory access protocol – used by Microsoft’s Active Directory product among others
  • The new framework is built using extension points, allowing Building Blocks to interact with the platform. If you are writing a custom authentication plugin, these are the two classes you will be working with.
  • These are some more extension points that the platform exposes, allowing you to intercept and modify the behaviour of the core system.AuthenticationListener receives notification whenever anything interesting happens related to authentication. Sample events include Login, Logout, SessionExpiry, and Failed Login.PostLoginUrlInterceptor could be used to alter the standard destination after a user logs in. For example, you could use this to send the user to the change password page when they log in for the very first time.UsernamePasswordAuthenticationProviderFilter allows you to disable individual authentication providers based on the current request context. We use this internally to implement the restricted hostnames feature, only allowing a provider to be used if the request was sent to a specific hostname.UsernamePasswordPreValidationCheck and UsernamePasswordPostValidationCheck allow you to abort a login request either before or after the password validation has occurred. We’ll be using these today to implement a filter that temporarily locks an account if too many bad login attempts are received in a short period of time.
  • In addition to the interfaces that you can implement within your Building Block, the new authentication framework includesa number of helper classes that you can call.Worth highlighting here is AuthenticationProvider. Building Blocks can supply AuthenticationProviderHandler implementations, telling the framework how to do your type of authentication. AuthenticationProvider represents a deployed instance of your handler. Administrators can deploy multiple instances of a single handler, each with their own properties. Each instance of fully delegated providers shows up as another link on the login screen, and each delegated credential provider gets called until one approves or denies the password-based login request.
  • This sequence diagram shows what happens during a fully delegated login. When the user logs in:Your handler provides the URL where you want the user to be sent to start the authentication processThe user is then sent to this URL and you can do whatever is necessary to confirm that the user is authentic. For example, with the CAS handler we bounce the user over to the CAS server, have them log in there, and then they get bounced back to our Building Block where we can validate the CAS responseOnce we know the user is authentic, we figure out which Blackboard Learn account to connect them with (either by username or batch_uid), and activate their session.
  • Delegated credential authentication is driven by Learn. Within this process, there are a number of places you can inject extensions to alter the system behaviour.
  • This is the interface for our helper class that we’ll use to keep track of login attempts.shouldBlock will be called before each login attemptsuccessfulLogin will be called after a login succeedslockedUntil provides information when reporting errorsI won’t go into the implementation of this class during today’s presentation. The essence of the implementation is a HashMap keyed by username storing all recent login attempts.Note: Some of the code shown here has been tweaked slightly to make the slides easier to read. The full code will be made available afterwards.
  • This is our first extension point.If the login counter indicates there have been too many attempts for this username, return UserDenied along with an informative error that will be shown to the end user
  • This is our second extension point. Since we know that the user entered a valid password, we’ll clear any previous login attempts. This ensures that users with valid credentials can log in and out as many times as they want.
  • Now it’s time to wire up our extension implementations. Most of this is boilerplate. A few things to notice, though:I’ve included a webapp-type element. This tells the platform that your Building Block includes extension implementations.The extension-defs element is where we register our specific extensions.First, we define our own namespace. This helps ensure that our extension IDs don’t collide with extensions from other Building Blocks.Next, we list the extensions themselves. Each extension has:A unique identifier.The identifier of the extension point being implemented. The fully qualified name of our implementation classA singleton flag, indicating that the platform may reuse the same instance of our extension each time
  • Here you can see the result after too many bad login attempts.
  • And here is what the administrator sees. The Error event is our custom event, which contains our “Too many login attempts” warning. Above this is the failed Login Attempt event that the framework logged because an extension point aborted the login, which includes the IP address of the attacker.
  • There are lots of things that you can do with the new authentication framework. To help you get started, we’ve released the source code for the LDAP provider which ships with the latest version of Blackboard Learn. We will also be making the full source code from today’s presentation available.The LDAP code is a compilable, runnable version of the shipping LDAP B2, in a separate namespace, so that they can be run in parallelThe sample code can be pulled from github, it is not intended to be run in production! It has several shortcuts and limitations as described in the readme file.
  • You can learn more about how the base features of the framework operate from the Learn Help CenterYou can learn more about Shibboleth and CAS from their own sites
  • Code your Own: Authentication Provider for Blackboard Learn

    1. 1. Code Your Own Learn Authentication Plugin #AuthcodeAlex VarjuArchitectBlackboard Product DevelopmentDan RinzelDesign ManagerBlackboard Product Development
    2. 2. Q’s we will try to A• How does internal authentication work in Blackboard Learn™?• What’s a remote authentication provider?• What’s a delegated credential provider?• What’s a fully delegated or redirect provider?• What changed in Blackboard Learn 9.1 SP8?• What providers are supported?• How can I extend this framework?
    3. 3. Blackboard Learn Default Authentication• Standard Username & Password combination• Passwords transmitted and stored as encrypted hashes (MD5 or SHA)• Usernames & Passwords can be SOURCED externally, but must be stored in local Learn database
    4. 4. Remote Authentication Provider• In conjunction or instead, Blackboard Learn can be incorporated with authentication services hosted elsewhere.• Passwords are stored and managed remotely, according to policies enforced by the remote provider• Usernames are matched or at least correlated
    5. 5. Delegated Credential Provider• Users log in via a Blackboard Learn screen• Credentials are checked programmatically via the remote provider and results relayed back to the user via Blackboard Learn    Browser Blackboard Learn Credential Provider
    6. 6. Fully Delegated Provider• Users log in directly to the remote provider• The user is redirected to Blackboard Learn with a valid session, vouched for by the provider     Browser Credential Provider Blackboard Learn
    7. 7. What Changed in Service Pack 8?What didn’t change?
    8. 8. What Changed in Service Pack 8?What didn’t change?
    9. 9. What Changed in Service Pack 8? Expanded customization capabilities for login page
    10. 10. What Changed in Service Pack 8?  Enhanced Logging for Authentication events
    11. 11. What Changed in Service Pack 8? New command-line emergency login URL generator
    12. 12. Provider Support in Service Pack 8 Updated Shibbolethsupport to version 2 –including support forApache 2 Official CAS Supportfor the first timeAutomatic update forexisting LDAPconfigurations Continued supportfor other customconfigurations viaLegacy provider
    13. 13. Built for ExtensionCore authentication classes:AuthenticationProviderHandler The entry point for all authentication providers. This provides us with the information needed to invoke your code at the right times.UsernamePasswordValidator For delegated credential providers, this is responsible for validating the username/password typed into the Blackboard Learn login box
    14. 14. Built for ExtensionAuthenticationListener For listening for authentication events.PostLoginUrlInterceptor To allow system to redirect through an alternate URL after login.UsernamePasswordAuthenticationProviderFilter To allow runtime checking of whether each authentication provider in the chain should be run.UsernamePasswordPreValidationCheck For pre-validation checks to be run before any authentication providers validation has been invoked.UsernamePasswordPostValidationCheck For post-validation checks to be run on the User that is returned from validation.
    15. 15. Built for ExtensionAuthenticationManager Search for users, redirect them back to the main page after successful login.SessionManager Grant the user a session once youve confirmed their identity.AuthenticationProviderManager Manage authentication provider instances. Useful if you need to save per-provider settings.AuthenticationLogger Record custom events in the authentication logs.AuthenticationProvider An administrator-created authentication instance
    16. 16. Fully delegated provider
    17. 17. Delegated credential provider• User submits password from the login screen• See if a UsernamePasswordPreValidationCheck wants to stop the login• Load sorted list of AuthenticationProviders• For each provider: • Do any UsernamePasswordAuthenticationProviderFilter extensions this provider to be skipped? • Call this providers UsernamePasswordValidator • Validator can return Yes, No, or I Dont Know.• If a provider accepted this login, see if any UsernamePasswordPostValidationCheck extensions want to stop the login
    18. 18. Working ExampleToday we’re going to walk through building a filter whichlimits prevents dictionary password guessing.Extension points we will make use of:• UsernamePasswordPreValidationCheck• UsernamePasswordPostValidationCheck
    19. 19. Working ExampleBasic design:• Intercept the login request before any password validation is performed.• If the same username has been seen too many times recently, block the login.• After a user has successfully logged in, reset the login counter so that they can log in and out multiple times.
    20. 20. Working Examplepublic interface LoginAttemptCounter { /** * Determines whether to block the login attempt for this username. Also * records the login attempt for future use. * * @return true if the request should be blocked, false if it may proceed */ public boolean shouldBlock(String username); /** * Indicates that this user logged in successfully, and that any previous * records associated with them may be removed. */ public void successfulLogin(String username); /** * Indicates what time the account will be unlocked. * * @return Time in millis, or 0 if account is not locked */ public long lockedUntil(String username);}
    21. 21. Working Examplepublic class BeforeLogin extends AbstractUsernamePasswordPreValidationCheck { private final LoginAttemptCounter counter = LoginAttemptCounter.Factory.getInstance(); private final AuthenticationLogger logger = AuthenticationLogger.Factory.getInstance(); @Override public ValidationResult preValidationChecks(String username, String password) { ValidationResult result = new ValidationResult(null); if (counter.shouldBlock(username)) { result.setStatus(ValidationStatus.UserDenied); long now = Calendar.getInstance().getTimeInMillis(); long lockedForMillis = counter.lockedUntil(username) - now; long lockedForSeconds = Math.round(lockedForMillis / 1000.0); result.setMessage(String.format("Account locked for %d seconds.", lockedForSeconds)); AuthenticationEvent event = buildAuthFailedEvent(username); logger.logAuthenticationEvent(event); } else { result.setStatus(ValidationStatus.Continue); } return result; } private AuthenticationEvent buildAuthFailedEvent(String username) { return new AuthenticationEvent(EventType.Error, new Date(), username, "Too many login attempts", null, null); }}
    22. 22. Working Examplepublic class AfterLogin extends AbstractUsernamePasswordPostValidationCheck { private final LoginAttemptCounter counter = LoginAttemptCounter.Factory.getInstance(); @Override public ValidationResult postValidationChecks(User user) { counter.successfulLogin(user.getUserName()); ValidationResult result = new ValidationResult(null); result.setStatus(ValidationStatus.Continue); return result; }}
    23. 23. Working Example = = =<webapp-type value="javaext" /> = = = = = =<extension-defs> <definition namespace="blackboard.sample.auth.filter"> <extension id="beforeLogin” point="blackboard.platform.authUserPassPreValidation” class="blackboard.sample.auth.filter.BeforeLogin” singleton="true" /> <extension id="afterLogin” point="blackboard.platform.authUserPassPostValidation” class="blackboard.sample.auth.filter.AfterLogin” singleton="true" /> </definition></extension-defs> = = =
    24. 24. Working Example
    25. 25. Working Example
    26. 26. Sample codeLDAP delegated credential provider Requires Behind the Blackboard credentialSample code - login rate limiter (github)
    27. 27. ResourcesBlackboard Learn Help Center http://help.blackboard.comShibboleth This presentation will be available via at some point after the 27 conference ends.