Hi All, I would like to know your opinion about the authentication API that is being used by PicketBox 5.You can check an initial documentation here: https://docs.jboss.org/author/display/SECURITY/PicketBox+Authentication+API. We are considering some requirements during the construction of this API. They are as follows: - Easy-to-use and fast to get started; - Flexible architecture providing ways to use different mechanisms like Username/Password, Digest, Certificates, SASL, etc; - Unified authentication API. Although you can use different mechanisms, the API usage is the same; - Allow authentication using multiple stores: properties, databases, ldap, etc; - Hide mechanism`s complexity from users. Users do not need to be aware of the complexities behind a specific mechanism; - Environment agnostic. You can use it in a pure Java SE application and in a JEE/CDI environment as well; - Challenge/Response design; - Authentication Events. Users should be able to observe specific authentication events like pre/pos authentication, failures, etc. - Auditing. Regards, Pedro Igor _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

Bare with me for a second please...

What exactly is a generic Authentication API buying you? What is the value in it? What exactly is it doing behind the scenes on the server? and on the client?

In the SASL example you gave it just seems weird to me that you are mixing a generic interface with a typed interface. You're tunneling information through a generic service, so why not just execute the SASL model directly?

I just don't think a generic Authentication API is very useful, because, depending on the protocol (HTTP, WebSocket, proprietary socket), that particular protocol is going to have to build the response back to the client anyways. Also for things like HTTP Digest, authentication is very wire protocol specific and really cannot be encapsulated in a generic component.

So, what do I suggest? Split things into 3 distinct API sets: metadata, metadata processing helper classes, and Subject/Roles/Permission propagation.

Metadata would be the SecurityDomain and a storage abstraction for security metadata. Helper classes are not part of a generic API, but instead are specific to the the metadata you want to process. Finally you need an API for defining and propagating Subject, roles, and permissions. All these things need to be separate, IMO, to give the greatest amount of flexibility for security protocol developers.

* In the first example, what is "authenticate" that you assert is not null? Without this, the example doesn't make much sense :-) * You should show some usage of the handler in this example as well. * In fact, looking at those examples I'm not sure how it is a callb, and not just a struct * You gone for a pattern half-way towards fluent configuration with the configuration, which I've found is normally a really bad place to be. I would go the whole way: ** Have a mutable builder class, ConfigurationBuilder, which has the fluent methods to configure all of PicketBox, which has a build() method ** Have a Configuration class, which is immutable, and emitted by the build method ** Have a constructor or static factory method on PicketBoxManager which takes a Configuration object This means that we can now easily create immutable (thread safe) configuration objects which can be passed around. This scheme will also work very well with CDI producers. * If mechanism, managers can be configured, then make sure you offer these as first class options on the Configuration e.g. configuration.authentication().userNamePasswordMechanism().allowBeavers() <-- works really nicely in IDEs * What you've called an observer, I think is actually a callback * You have an error in the SASL example, authenticate is not a local variable, and it's not complete (add javadoc to discuss missing methods?) On 31 Jul 2012, at 21:01, Pedro Igor Silva wrote: > Hi All, > > I would like to know your opinion about the authentication API that is being used by PicketBox 5.You can check an initial documentation here: https://docs.jboss.org/author/display/SECURITY/PicketBox+Authentication+API. > > We are considering some requirements during the construction of this API. They are as follows: > > - Easy-to-use and fast to get started; > - Flexible architecture providing ways to use different mechanisms like Username/Password, Digest, Certificates, SASL, etc; > - Unified authentication API. Although you can use different mechanisms, the API usage is the same; > - Allow authentication using multiple stores: properties, databases, ldap, etc; > - Hide mechanism`s complexity from users. Users do not need to be aware of the complexities behind a specific mechanism; > - Environment agnostic. You can use it in a pure Java SE application and in a JEE/CDI environment as well; > - Challenge/Response design; > - Authentication Events. Users should be able to observe specific authentication events like pre/pos authentication, failures, etc. > - Auditing. > > Regards, > Pedro Igor > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

On 7/31/12 8:48 PM, Pedro Igor Silva wrote: > ----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: security-dev(a)lists.jboss.org > Sent: Tuesday, July 31, 2012 7:26:58 PM > Subject: Re: [security-dev] [PicketBox 5] - Authentication API > >> Bare with me for a second please... >> What exactly is a generic Authentication API buying you? What is the >> value in it? What exactly is it doing behind the scenes on the server? >> and on the client? > I prefer to think this API as a framework for building authentication for client and services. Providing some common capabilities like exception handling, event handling, authentication workflow, user stores integration, subject propagation, etc). I dig deeper, but exception handling, event handling is often very specific to the wire protocol and component layer you're authenticating. Authentication workflow can be very application specific and custom. Can you provide an example? For user stores integration, instead of hiding it, expose the user store. This is one of the main problems of the current picketlink. Everything is so hidden, it is really really hard to do anything beyond what it is narrowly designed for. > I pushed the examples to the PicketBox Quickstarts repo: https://github.com/picketbox/picketbox-quickstarts/tree/master/auth-api-e.... > >> In the SASL example you gave it just seems weird to me that you are >> mixing a generic interface with a typed interface. You're tunneling >> information through a generic service, so why not just execute the SASL >> model directly? > I agree you can use SASL directly, but you`ll loose some capabilities provided by the API like: user validation using some specific data store (i think you call this security domain/storage), event handling and > others that we can plug and reuse between implementations. > Again, expose the store and do the validation in your protocol layer. >> I just don't think a generic Authentication API is very useful, because, >> depending on the protocol (HTTP, WebSocket, proprietary socket), that >> particular protocol is going to have to build the response back to the >> client anyways. Also for things like HTTP Digest, authentication is >> very wire protocol specific and really cannot be encapsulated in a >> generic component. > I partially agree. Can you take a look at the HTTP Digest example ? https://github.com/picketbox/picketbox-quickstarts/blob/master/auth-api-e... > > The service logic is the same used by the PicketBox "default" HTTP Digest implementation. > >> So, what do I suggest? Split things into 3 distinct API sets: metadata, >> metadata processing helper classes, and Subject/Roles/Permission >> propagation. >> Metadata would be the SecurityDomain and a storage abstraction for >> security metadata. Helper classes are not part of a generic API, but >> instead are specific to the the metadata you want to process. Finally >> you need an API for defining and propagating Subject, roles, and >> permissions. All these things need to be separate, IMO, to give the >> greatest amount of flexibility for security protocol developers. > We are calling the SecurityDomain as AuthenticationManager. The AuthenticationManager is responsible for validating the user`s credential against a specific store (ldap, properties, database, etc). The other parts are being implemented. > So, IMO, the user store should be exposed and separate from validation. I'll look at your HTTP Digest example, but this is a perfect reason why validation in a generic service cannot be done. > Btw, the SASL example considers a simple scenario. That is why I opened the discussion, I'm sure there are more use cases to stress this design. > You'd be better off writing down the requirements of each use case. Because right now, what you have just looks like fluent JAAS. Same sort of unflexible model. I'll try and put some pseudo code together. Bill

Bill, the auth api was mainly done as a prototype for the AS guys. Your use cases may require direct access to the Identity Store. We support the direct usage as shown in the http digest quickstart. Regards, Anil On 08/01/2012 08:03 AM, Bill Burke wrote: > > On 7/31/12 8:48 PM, Pedro Igor Silva wrote: >> ----- Original Message ----- >> From: "Bill Burke" <bburke(a)redhat.com&gt; >> To: security-dev(a)lists.jboss.org >> Sent: Tuesday, July 31, 2012 7:26:58 PM >> Subject: Re: [security-dev] [PicketBox 5] - Authentication API >> >>> Bare with me for a second please... >>> What exactly is a generic Authentication API buying you? What is the >>> value in it? What exactly is it doing behind the scenes on the server? >>> and on the client? >> I prefer to think this API as a framework for building authentication for client and services. Providing some common capabilities like exception handling, event handling, authentication workflow, user stores integration, subject propagation, etc). > I dig deeper, but exception handling, event handling is often very > specific to the wire protocol and component layer you're authenticating. > Authentication workflow can be very application specific and custom. > Can you provide an example? For user stores integration, instead of > hiding it, expose the user store. This is one of the main problems of > the current picketlink. Everything is so hidden, it is really really > hard to do anything beyond what it is narrowly designed for. > >> I pushed the examples to the PicketBox Quickstarts repo: https://github.com/picketbox/picketbox-quickstarts/tree/master/auth-api-e.... >> >>> In the SASL example you gave it just seems weird to me that you are >>> mixing a generic interface with a typed interface. You're tunneling >>> information through a generic service, so why not just execute the SASL >>> model directly? >> I agree you can use SASL directly, but you`ll loose some capabilities provided by the API like: user validation using some specific data store (i think you call this security domain/storage), event handling and >> others that we can plug and reuse between implementations. >> > Again, expose the store and do the validation in your protocol layer. > >>> I just don't think a generic Authentication API is very useful, because, >>> depending on the protocol (HTTP, WebSocket, proprietary socket), that >>> particular protocol is going to have to build the response back to the >>> client anyways. Also for things like HTTP Digest, authentication is >>> very wire protocol specific and really cannot be encapsulated in a >>> generic component. >> I partially agree. Can you take a look at the HTTP Digest example ? https://github.com/picketbox/picketbox-quickstarts/blob/master/auth-api-e... >> >> The service logic is the same used by the PicketBox "default" HTTP Digest implementation. >> >>> So, what do I suggest? Split things into 3 distinct API sets: metadata, >>> metadata processing helper classes, and Subject/Roles/Permission >>> propagation. >>> Metadata would be the SecurityDomain and a storage abstraction for >>> security metadata. Helper classes are not part of a generic API, but >>> instead are specific to the the metadata you want to process. Finally >>> you need an API for defining and propagating Subject, roles, and >>> permissions. All these things need to be separate, IMO, to give the >>> greatest amount of flexibility for security protocol developers. >> We are calling the SecurityDomain as AuthenticationManager. The AuthenticationManager is responsible for validating the user`s credential against a specific store (ldap, properties, database, etc). The other parts are being implemented. >> > So, IMO, the user store should be exposed and separate from validation. > I'll look at your HTTP Digest example, but this is a perfect reason > why validation in a generic service cannot be done. > > >> Btw, the SASL example considers a simple scenario. That is why I opened the discussion, I'm sure there are more use cases to stress this design. >> > You'd be better off writing down the requirements of each use case. > Because right now, what you have just looks like fluent JAAS. Same sort > of unflexible model. > > I'll try and put some pseudo code together. > > Bill > _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

Hi Bill, I think one of the main things about this API is that when creating new mechanisms you focus only in its logic. The mechanism only needs to know how to extract the user's credentials (eg.: by using a specific protocol) and call an authentication manager (user metadata store) to validate its credentials. The user store is not hidden it is available during the authentication. Also, other aspects like subject creation/population/propagation are handled by PicketBox. I think you do not need to code that every time. Of course, the API may provide extensions for custom and specific behaviour.

Another idea is allow multiple user stores during the user validation, that is configurable. We can also have some policy for the stores like stop in the first successful validation or require all stores to validate the user.

I understand that exception,event handling and workflow are specific, but as the authentication is managed by PicketBox it can also help protocols and components to customize some behaviour by listening for certain events or extending the API.

I think the indirection is important to reuse mechanisms whithout wiring them with the protocol/component environment. We can use the HTTP Digest mechanism, for example, inside a filter, jsp page, servlet or in a Valve or even share it between projects.

About the callback stuff, as Pete said, it seems more like a struct. And I agree. We are looking to change this concept.

Bill, there are some indirections that need to be eliminated as you have pointed out. Thanks for the feedback. Regards, Anil On 08/01/2012 07:26 PM, Bill Burke wrote: > On 8/1/12 6:35 PM, Pedro Igor Silva wrote: >> Hi Bill, >> >> I think one of the main things about this API is that when creating new mechanisms you focus only in its logic. The mechanism only needs to know how to extract the user's credentials (eg.: by using a specific protocol) and call an authentication manager (user metadata store) to validate its credentials. The user store is not hidden it is available during the authentication. Also, other aspects like subject creation/population/propagation are handled by PicketBox. I think you do not need to code that every time. Of course, the API may provide extensions for custom and specific behaviour. >> > Creating reusable helper classes is useful. But I don't see the value > of the multiple level of indirections you are requiring. Its too much > like what we already have. > > >> Another idea is allow multiple user stores during the user validation, that is configurable. We can also have some policy for the stores like stop in the first successful validation or require all stores to validate the user. >> > Multiple user stores needs to be captured in a requirements document! > > This idea of generic validation works great for username/password. > Fails miserably for everything else because the algorithm is different. > Just think of the number validators you're going to have to write: > > user/password > http digest > client cert > totp > > I think a better interface might be: > > interface Authenticator { > > void authenticate(Metadata metadata); > } > > interface AuthenticationManager { > Subject authenticate(Authenticator); > } > > class HttpDigest extends Authenticator { > > void authenticate(Metadata metadata) { > String password = metdata.getAttribute("password"); > .. build hashes.. > } > } > > > void filter(HttpServletRequest request, HttpServletResponse response) > { > String authHeader = request.getHeader("Authorization"); > HttpDigest digest = > request.getSession().getAttribute(HttpDigest.class.getName()); > if (digest == null) > { > digest = new HttpDigest(); > request.getSession().setAttribute(HttpDigest.class.getName()); > } > > digest.addAuthHeader(authHeader); > > AuthenticationManager manager = ...; // injected, looked up, > whatever... > > try { > subject = manager.authenticate(digest); > Picketbox.propagate(subject); > } catch (SecurityException exc) { > String authenticateHeader = digest.getAuthenticateHeader(); > ... add this to servlet response ... > } > } > > > The above filter() method would be different if reused with Netty, Sun > Http JDK, or Catalina. With the above code you don't need all those > callback abstractions. You also have a completely typed interface. > Also, the HttpDigest class could hold state between requests so nonces > could be compared between requests. How the state is stored is really > up to the component layer. HttpDigest could even be a app-server level > service so that true comparison of nonces could be done per user. > Really all we care about here from Picketlink is the user metadata > store. The rest should be controlled by the component/protocol layer. > > > >> I understand that exception,event handling and workflow are specific, but as the authentication is managed by PicketBox it can also help protocols and components to customize some behaviour by listening for certain events or extending the API. >> > Is this theoretical, or a reality? Write these down in requirements > document. Specify which events that should be able to listen to and why. > >> I think the indirection is important to reuse mechanisms whithout wiring them with the protocol/component environment. We can use the HTTP Digest mechanism, for example, inside a filter, jsp page, servlet or in a Valve or even share it between projects. >> > Not possible. Because a filter would use HttpServletRequest/Response, > Valve would use something Catalina specific, Netty and Sun JDK HTTP > would have their own HTTP abstractions. Sure, write reusable helper > classes that accept the information you need to process, but what does a > generic callback system buy you? > >> About the callback stuff, as Pete said, it seems more like a struct. And I agree. We are looking to change this concept. >> > I really think you guys need to focus on the requirements document. It > will flush out your design better and help you avoid the ditches you dug > yourself into with the old APIs. > > Bill > >

BTW, Anil, I'm just trying to help. Give feedback, etc. I do think though you guys really need to have a more detailed requirements document. It will really help flushing out the design. On 8/6/12 2:32 PM, Anil Saldhana wrote: > Bill, > based on your feedback, I created this brainstorming article: > https://community.jboss.org/wiki/AuthenticationAPIDesign > > Regards, > Anil > > On 08/06/2012 11:20 AM, Anil Saldhana wrote: >> Bill, >> there are some indirections that need to be eliminated as you have >> pointed out. Thanks for the feedback. >> >> Regards, >> Anil >> >> On 08/01/2012 07:26 PM, Bill Burke wrote: >>> On 8/1/12 6:35 PM, Pedro Igor Silva wrote: >>>> Hi Bill, >>>> >>>> I think one of the main things about this API is that when creating new mechanisms you focus only in its logic. The mechanism only needs to know how to extract the user's credentials (eg.: by using a specific protocol) and call an authentication manager (user metadata store) to validate its credentials. The user store is not hidden it is available during the authentication. Also, other aspects like subject creation/population/propagation are handled by PicketBox. I think you do not need to code that every time. Of course, the API may provide extensions for custom and specific behaviour. >>>> >>> Creating reusable helper classes is useful. But I don't see the value >>> of the multiple level of indirections you are requiring. Its too much >>> like what we already have. >>> >>> >>>> Another idea is allow multiple user stores during the user validation, that is configurable. We can also have some policy for the stores like stop in the first successful validation or require all stores to validate the user. >>>> >>> Multiple user stores needs to be captured in a requirements document! >>> >>> This idea of generic validation works great for username/password. >>> Fails miserably for everything else because the algorithm is different. >>> Just think of the number validators you're going to have to write: >>> >>> user/password >>> http digest >>> client cert >>> totp >>> >>> I think a better interface might be: >>> >>> interface Authenticator { >>> >>> void authenticate(Metadata metadata); >>> } >>> >>> interface AuthenticationManager { >>> Subject authenticate(Authenticator); >>> } >>> >>> class HttpDigest extends Authenticator { >>> >>> void authenticate(Metadata metadata) { >>> String password = metdata.getAttribute("password"); >>> .. build hashes.. >>> } >>> } >>> >>> >>> void filter(HttpServletRequest request, HttpServletResponse response) >>> { >>> String authHeader = request.getHeader("Authorization"); >>> HttpDigest digest = >>> request.getSession().getAttribute(HttpDigest.class.getName()); >>> if (digest == null) >>> { >>> digest = new HttpDigest(); >>> request.getSession().setAttribute(HttpDigest.class.getName()); >>> } >>> >>> digest.addAuthHeader(authHeader); >>> >>> AuthenticationManager manager = ...; // injected, looked up, >>> whatever... >>> >>> try { >>> subject = manager.authenticate(digest); >>> Picketbox.propagate(subject); >>> } catch (SecurityException exc) { >>> String authenticateHeader = digest.getAuthenticateHeader(); >>> ... add this to servlet response ... >>> } >>> } >>> >>> >>> The above filter() method would be different if reused with Netty, Sun >>> Http JDK, or Catalina. With the above code you don't need all those >>> callback abstractions. You also have a completely typed interface. >>> Also, the HttpDigest class could hold state between requests so nonces >>> could be compared between requests. How the state is stored is really >>> up to the component layer. HttpDigest could even be a app-server level >>> service so that true comparison of nonces could be done per user. >>> Really all we care about here from Picketlink is the user metadata >>> store. The rest should be controlled by the component/protocol layer. >>> >>> >>> >>>> I understand that exception,event handling and workflow are specific, but as the authentication is managed by PicketBox it can also help protocols and components to customize some behaviour by listening for certain events or extending the API. >>>> >>> Is this theoretical, or a reality? Write these down in requirements >>> document. Specify which events that should be able to listen to and why. >>> >>>> I think the indirection is important to reuse mechanisms whithout wiring them with the protocol/component environment. We can use the HTTP Digest mechanism, for example, inside a filter, jsp page, servlet or in a Valve or even share it between projects. >>>> >>> Not possible. Because a filter would use HttpServletRequest/Response, >>> Valve would use something Catalina specific, Netty and Sun JDK HTTP >>> would have their own HTTP abstractions. Sure, write reusable helper >>> classes that accept the information you need to process, but what does a >>> generic callback system buy you? >>> >>>> About the callback stuff, as Pete said, it seems more like a struct. And I agree. We are looking to change this concept. >>>> >>> I really think you guys need to focus on the requirements document. It >>> will flush out your design better and help you avoid the ditches you dug >>> yourself into with the old APIs. >>> >>> Bill >>> >>> >>>