I'll try to write a blog about this too, but, the security APIs/SPIs really need a rethink. Originally, the whole security-domain concept, and Tomcat Realm centered around passwords or an X509Certificate (for client cert). Passwords alone basically suck for security. We use a soft or hard token for our VPN, why wouldn't we use something similar for JBoss-deployed applications? There's all different kinds of information that needs to be stored in a security-domain now: - passwords - hashed passwords - secret-keys (for TOTP, soft-tokens) - remembering nonces (Digest and OAuth come to mind hear) - remember request and access tokens (Think OAuth) - URLs (Think OpenID) - KeyPairs when you're dealing with digital signatures or client certificate authentication - JPG images. Think of Bank of America that shows you a secret image when you log in so that you know somebody isn't spoofing their site. - Client IP addresses for when you want to tie a user to a client IP Our legacy APIs/SPIs worked nicely because, since everything was password based, the Security-Domain could also do authentication. Extract the username/password from the HTTP request (or remote EJB request) and just check it vs. the password storage. Now though, there's a growing set of protocols that need access to the HTTP request itself, especially if the request is digitally signed in some manner, and the line between the protocol and security-domain starts to really blur. Another huge problem with our security SPIs is that LoginModules are stateless. There's really no way, other than hacks, to point it at specific storage so it can do things like: remember nonces, temporary secrets or certificates, previous IP address connections. Yet another that I think may come up is dual-authentication mechanisms for the same resources (URLs). A regular user may query the site via traditional authentication vs. a 3rd party consumer which uses OAuth. With our current WAR/web.xml model, you can only use one or the other. The final problem I'm currently seeing is that its hard to re-use the storage capabilities of our security plugins (.properites, ldap, JDBC, etc.). What you currently have is a mish-mash of weird, hard-to extend class hierarchies with no clear line between storage of information and the algorithm being used and the process of authentication and authorization. If we're going to support more complex models, we need to create better SPIs here. So what to do? #1 I suggest defining a Security Storage SPI. Something that is key/value/values based that is listable. i.e. something like: interface SecurityStore { public Object get(String key); public List<Object> list(String key); public void put(String key, Object value); public void put(String key, List<Object> value); } A key would look like a URL i.e.: /users /users/bill /users/bill/private-key /users/bill/public-key /users/bill/password /users/bill/totp-key /applications/myapp /applications/myapp/roles /applications/myapp/roles/admin /applications/myapp/roles/admin/users /applications/myapp/roles/admin/users/bill The the security store could be mapped to a properties file, XML file, LDAP storage, JDBC, etc. Whether or not we use an existing thing here i.e. Infinispan, JCR, or whatever is irrelevant, but we need a simple generic storage mechanism to give ultimate flexibility to security extension developers. Some suggestions on what to use for this mechanism would be greatly appreciated. #2 Deprecate JAAS and write our own SPIs/APIs. #3 Decide where authentication happens. Does it happen within a Tomcat Valve and persistent security information queried directly from the SecurityStore? Do we have a Security domain and delegate to it for authentication? (In this case, the Security-Domain would need access to the request object). I think I prefer a full delegation to a SecurityDomain as storage, the authentication mechanism, and configuration of the authentication mechanism pretty much go hand in hand. #4 We need to make it fairly easy to develop security extensions. #5 Try to support legacy deployment options with the new model. #6 Going along with #3, I really like the idea of adding a <auth-method> of JBOSS, or JBOSS-SECURITY-DOMAIN, so that authentication is handling fully by a JBoss subsystem. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

I'm going to put on my Bill hat here and say, "JSR 196 is crap".

I've been saying this exact thing for over a year now. And the response has ever been "we'll have a call, we'll talk about it, we'll gather requirements, let's write an agenda, get some minutes, talk talk talk talk".

On 09/22/2011 05:56 PM, Bill Burke wrote: > On 9/22/11 5:46 PM, David M. Lloyd wrote: >> I'm going to put on my Bill hat here and say, "JSR 196 is crap". >> > Its not just JSR196. SAML is crap. XACML is crap. Its horrible > horrible stuff. The only reason we should implement it is to integrate > with other vendor's products. I am not preaching JSR 196 here. Because of EE6, my team has to implement it for AS7.1. I don't magically get hours to figure out abstract uber APIs and slowly plug in the EE specs. That way, security is a mess. Too bad, you don't get a call when there is a major issue with some security mechanism that was put in some weird corner of the JBoss ecosystem.

> Also plugging in your own authentication mechanism in AS7 is crap too, > specially, modules are a mess. Unless you fixed some things in the last > month. But thats another conversation I want to have. > Rather than just complaining, please provide feedback on what gives you a heartburn. Suggest alternatives. It is not like I have a telepathic hat to just wear and understand you.

>> I've been saying this exact thing for over a year now. And the response >> has ever been "we'll have a call, we'll talk about it, we'll gather >> requirements, let's write an agenda, get some minutes, talk talk talk talk". >> > Yup. I can't wait any longer. Too many of our users want our OAuth > work integrated. THere's a whole story around security, web-apps, and > REST I'm trying to putting together as well. The thing is we also need > some *real* management on this stuff as well. > For your kind information, OAuth spec is not even final. I think they are at Draft 21 and hopefully in this millennium, they will finish the spec. Same goes with OpenID also. OpenID schema types refer to www.axschema.org and that domain does not even exist.

On 09/22/2011 05:56 PM, Bill Burke wrote: > Also plugging in your own authentication mechanism in AS7 is crap too, > specially, modules are a mess. Unless you fixed some things in the last > month. But thats another conversation I want to have. Bring it ;)

On 9/23/11 8:44 AM, Bill Burke wrote: > > On 9/22/11 7:13 PM, David M. Lloyd wrote: >> On 09/22/2011 05:56 PM, Bill Burke wrote: >>> Also plugging in your own authentication mechanism in AS7 is crap too, >>> specially, modules are a mess. Unless you fixed some things in the last >>> month. But thats another conversation I want to have. >> Bring it ;) >> > I think I've already talked about it in the past. If you want to extend > JBoss at all (i.e. a security plugin) you have to hack the modules/ > directory so that classes are visible. Since you've pretty much > isolated applications from app-server classloaders, I'll put $100 down > that this issue exists for other extension points as well. Yeah that is completely wrong. I'm doing some management related fixes to the security subsystem and I am going to add a module attribute similar to the way the other extensibility mechanisms work (module="org.foo.mymodule" class="blahplugin"). JDBC drivers are also allowed to be deployables and we could do something similar with security plugins, although that will require more involved changes to picketlink/box.

On 9/23/11 9:55 AM, Jason T. Greene wrote: > On 9/23/11 8:44 AM, Bill Burke wrote: >> >> >> On 9/22/11 7:13 PM, David M. Lloyd wrote: >>> On 09/22/2011 05:56 PM, Bill Burke wrote: >>>> Also plugging in your own authentication mechanism in AS7 is crap too, >>>> specially, modules are a mess. Unless you fixed some things in the last >>>> month. But thats another conversation I want to have. >>> >>> Bring it ;) >>> >> >> I think I've already talked about it in the past. If you want to extend >> JBoss at all (i.e. a security plugin) you have to hack the modules/ >> directory so that classes are visible. Since you've pretty much >> isolated applications from app-server classloaders, I'll put $100 down >> that this issue exists for other extension points as well. > > Yeah that is completely wrong. > > I'm doing some management related fixes to the security subsystem and I > am going to add a module attribute similar to the way the other > extensibility mechanisms work (module="org.foo.mymodule" > class="blahplugin"). JDBC drivers are also allowed to be deployables and > we could do something similar with security plugins, although that will > require more involved changes to picketlink/box. > Not sure I'm understanding. So you're requiring users to configure that they want a specific module imported?

I'll try to write a blog about this too, but, the security APIs/SPIs really need a rethink. Originally, the whole security-domain concept, and Tomcat Realm centered around passwords or an X509Certificate (for client cert). Passwords alone basically suck for security. We use a soft or hard token for our VPN, why wouldn't we use something similar for JBoss-deployed applications?

There's all different kinds of information that needs to be stored in a security-domain now: - passwords - hashed passwords - secret-keys (for TOTP, soft-tokens) - remembering nonces (Digest and OAuth come to mind hear) - remember request and access tokens (Think OAuth) - URLs (Think OpenID) - KeyPairs when you're dealing with digital signatures or client certificate authentication

- JPG images. Think of Bank of America that shows you a secret image when you log in so that you know somebody isn't spoofing their site.

- Client IP addresses for when you want to tie a user to a client IP Our legacy APIs/SPIs worked nicely because, since everything was password based, the Security-Domain could also do authentication. Extract the username/password from the HTTP request (or remote EJB request) and just check it vs. the password storage. Now though, there's a growing set of protocols that need access to the HTTP request itself, especially if the request is digitally signed in some manner, and the line between the protocol and security-domain starts to really blur.

Another huge problem with our security SPIs is that LoginModules are stateless. There's really no way, other than hacks, to point it at specific storage so it can do things like: remember nonces, temporary secrets or certificates, previous IP address connections. Yet another that I think may come up is dual-authentication mechanisms for the same resources (URLs). A regular user may query the site via traditional authentication vs. a 3rd party consumer which uses OAuth. With our current WAR/web.xml model, you can only use one or the other. The final problem I'm currently seeing is that its hard to re-use the storage capabilities of our security plugins (.properites, ldap, JDBC, etc.). What you currently have is a mish-mash of weird, hard-to extend class hierarchies with no clear line between storage of information and the algorithm being used and the process of authentication and authorization. If we're going to support more complex models, we need to create better SPIs here. So what to do? #1 I suggest defining a Security Storage SPI. Something that is key/value/values based that is listable. i.e. something like: interface SecurityStore { public Object get(String key); public List<Object> list(String key); public void put(String key, Object value); public void put(String key, List<Object> value); } A key would look like a URL i.e.: /users /users/bill /users/bill/private-key /users/bill/public-key /users/bill/password /users/bill/totp-key /applications/myapp /applications/myapp/roles /applications/myapp/roles/admin /applications/myapp/roles/admin/users /applications/myapp/roles/admin/users/bill The the security store could be mapped to a properties file, XML file, LDAP storage, JDBC, etc. Whether or not we use an existing thing here i.e. Infinispan, JCR, or whatever is irrelevant, but we need a simple generic storage mechanism to give ultimate flexibility to security extension developers. Some suggestions on what to use for this mechanism would be greatly appreciated.

#2 Deprecate JAAS and write our own SPIs/APIs.

#3 Decide where authentication happens. Does it happen within a Tomcat Valve and persistent security information queried directly from the SecurityStore? Do we have a Security domain and delegate to it for authentication? (In this case, the Security-Domain would need access to the request object). I think I prefer a full delegation to a SecurityDomain as storage, the authentication mechanism, and configuration of the authentication mechanism pretty much go hand in hand.

#4 We need to make it fairly easy to develop security extensions. #5 Try to support legacy deployment options with the new model. #6 Going along with #3, I really like the idea of adding a<auth-method> of JBOSS, or JBOSS-SECURITY-DOMAIN, so that authentication is handling fully by a JBoss subsystem.

There is also a new identity jsr for updating the java ee/se security apis: http://jcp.org/en/jsr/detail?id=351 On 9/22/11 4:38 PM, Anil Saldhana wrote: > Detailed Response here:- > > On 09/22/2011 04:23 PM, Bill Burke wrote: >> I'll try to write a blog about this too, but, the security APIs/SPIs >> really need a rethink. Originally, the whole security-domain concept, >> and Tomcat Realm centered around passwords or an X509Certificate (for >> client cert). Passwords alone basically suck for security. We use a >> soft or hard token for our VPN, why wouldn't we use something similar >> for JBoss-deployed applications? >> > Security domain is just an abstract concept to pool in together > authentication/authorization/mapping/audit mechanisms etc. There is no > coupling to passwords. > >> There's all different kinds of information that needs to be stored in a >> security-domain now: >> >> - passwords >> - hashed passwords >> - secret-keys (for TOTP, soft-tokens) >> - remembering nonces (Digest and OAuth come to mind hear) >> - remember request and access tokens (Think OAuth) >> - URLs (Think OpenID) >> - KeyPairs when you're dealing with digital signatures or client >> certificate authentication >> - JPG images. Think of Bank of America that shows you a secret image >> when you log in so that you know somebody isn't spoofing their site. > This is a variant of "Knowledge based authentication" which gives an > additional layer of security rather than an additional factor of > authentication. > >> - Client IP addresses for when you want to tie a user to a client IP >> >> Our legacy APIs/SPIs worked nicely because, since everything was >> password based, the Security-Domain could also do authentication. >> Extract the username/password from the HTTP request (or remote EJB >> request) and just check it vs. the password storage. Now though, >> there's a growing set of protocols that need access to the HTTP request >> itself, especially if the request is digitally signed in some manner, >> and the line between the protocol and security-domain starts to really blur. >> > Just write a Tomcat authenticator. You don't have to go through the > context/realm or any of the heartburning issues you have. > >> Another huge problem with our security SPIs is that LoginModules are >> stateless. There's really no way, other than hacks, to point it at >> specific storage so it can do things like: remember nonces, temporary >> secrets or certificates, previous IP address connections. >> >> Yet another that I think may come up is dual-authentication mechanisms >> for the same resources (URLs). A regular user may query the site via >> traditional authentication vs. a 3rd party consumer which uses OAuth. >> With our current WAR/web.xml model, you can only use one or the other. >> >> The final problem I'm currently seeing is that its hard to re-use the >> storage capabilities of our security plugins (.properites, ldap, JDBC, >> etc.). What you currently have is a mish-mash of weird, hard-to extend >> class hierarchies with no clear line between storage of information and >> the algorithm being used and the process of authentication and >> authorization. If we're going to support more complex models, we need >> to create better SPIs here. >> >> So what to do? >> >> #1 I suggest defining a Security Storage SPI. Something that is >> key/value/values based that is listable. i.e. something like: >> >> interface SecurityStore { >> >> public Object get(String key); >> public List<Object> list(String key); >> public void put(String key, Object value); >> public void put(String key, List<Object> value); >> >> } >> >> A key would look like a URL i.e.: >> >> /users >> /users/bill >> /users/bill/private-key >> /users/bill/public-key >> /users/bill/password >> /users/bill/totp-key >> /applications/myapp >> /applications/myapp/roles >> /applications/myapp/roles/admin >> /applications/myapp/roles/admin/users >> /applications/myapp/roles/admin/users/bill >> >> The the security store could be mapped to a properties file, XML file, >> LDAP storage, JDBC, etc. >> >> Whether or not we use an existing thing here i.e. Infinispan, JCR, or >> whatever is irrelevant, but we need a simple generic storage mechanism >> to give ultimate flexibility to security extension developers. Some >> suggestions on what to use for this mechanism would be greatly appreciated. >> > Please influence the PicketLink IDM project. That is where the security > store api needs to be refined to your needs. > >> #2 Deprecate JAAS and write our own SPIs/APIs. >> > Agree on this. JAAS is cumbersome for developers. >> #3 Decide where authentication happens. Does it happen within a Tomcat >> Valve and persistent security information queried directly from the >> SecurityStore? Do we have a Security domain and delegate to it for >> authentication? (In this case, the Security-Domain would need access to >> the request object). I think I prefer a full delegation to a >> SecurityDomain as storage, the authentication mechanism, and >> configuration of the authentication mechanism pretty much go hand in hand. > You came back to the security domain/realm abstraction. >> #4 We need to make it fairly easy to develop security extensions. >> >> #5 Try to support legacy deployment options with the new model. >> >> #6 Going along with #3, I really like the idea of adding a<auth-method> >> of JBOSS, or JBOSS-SECURITY-DOMAIN, so that authentication is handling >> fully by a JBoss subsystem. > I mentioned about writing your own authenticator. You can use that to > short circuit the JBoss Web security infrastructure.