Discussions

News: Atlassian Crowd 1.0 for Web App SSO

  1. Atlassian Crowd 1.0 for Web App SSO (22 messages)

    Atlassian Software Systems today announced the general availability of Crowd 1.0, a single sign-on application for helping manage authentication and authorisation for multiple web-based applications. Crowd enables IT administrators and application developers to quickly integrate and deploy single sign-on using popular directories such as Microsoft Active Directory and Apple OS X Open Directory. As well as giving IT administrators a single consolidated point of user management, Crowd gives end-users the convenience of single sign-on across Atlassian JIRA, Confluence, or any other non-Atlassian, web-based applications in their business. Crowd is free for open source projects and non-profits. Commercial prices start at $600.00 USD. A fully functional 30-day evaluation of Crowd is available at http://www.atlassian.com/software/crowd.

    Threaded Messages (22)

  2. Congralations on the release! Atlassian Confluence (the wiki) is still my favorite, but we're also using Atlassian Crowd (with Confluence as well as some other apps like Jive Forums) and it's working out pretty well. To be fair, this was not entirely painless for us (we were using some early alphas -- ouch!), and it's still a 1.0 product with some rough edges, but we've been in production with it now for a couple months and I think our last known bug with Crowd was recently resolved. (Our implementation was done by Appfire here in Boston, and they've written up a case study on it.) Peace, Cameron Purdy Tangosol Coherence: Data Grid
  3. Before few days.. i was searching for an opensource SSO solution, I have tried many (JOSSO,JAAS wid Kerberos, spnego, OpenSSO, Yale CAS) but most of them have some limitations.. As I need to support User profiles stored in RDBMS (MySql) While most of them requirs User profiles to be stored in Active Directory or some other directory servers. JOSSO do the work for me but it doesnt support Apache Geronio. Yale Cas works wid most of the app servers and supports RDBMS, but doest provide support for authorization (Roles/Groups) What abt Crowd. do it fulfills all my needs? Sudhir Nimavat. Http://www.jyog.com
  4. Have a look at Penrose[ Go to top ]

    Before few days.. i was searching for an opensource SSO solution,
    I have tried many
    (JOSSO,JAAS wid Kerberos, spnego, OpenSSO, Yale CAS)
    but most of them have some limitations..
    All products have limitations .... I guess you'll have to live with that.
    As I need to support User profiles stored in RDBMS (MySql)
    While most of them requirs User profiles to be stored in
    Active Directory or some other directory servers.

    JOSSO do the work for me but it doesnt support Apache Geronio.

    Yale Cas works wid most of the app servers and supports RDBMS, but doest
    provide support for authorization (Roles/Groups)


    What abt Crowd. do it fulfills all my needs?
    I don't know Crowd but have a look at Penrose (http://docs.safehaus.org/display/PENROSE/Home). It allows you to publish the profiles in your RDBMS as LDAP. After you've done this you can use one of the other SSO tools available to implement SSO with roles.
  5. Re: Atlassian Crowd 1.0 for Web App SSO[ Go to top ]

    Hello Sudhir, You may want to take a look at OpenIAM from Diamelle Technologies (www.diamelle.com). While we we are getting ready to release version 3 in the next couple of weeks, all versions have supported multiple repositories - Directories and RDBMS. The following repositories are supported (Mysql, Oracle, MS Sql Server, Db2, OpenLDAP, Sun Directory Server). The Access Manager does support groups and roles and the ability to define no trivial policies around these roles. In addition to the normal CRUD type of privileges that you may assign to a resource and role, you can also define policies around location and time. For example, you could define a policy that say that if a user profile indicates that a person is based in the US, but is accessing the system from the far east, then dont allow them in between a certain time window. For SSO, there are a number of options to facilitate integration. Please let me know if you have any questions. Suneet Shah www.diamelle.com
  6. Hi Suneet, Interesting approach ! But doesn't this overlap with Business Rules Management Systems (BRMS), like e.g. ILOG JRules ? Cheers Remi
  7. Hi Remi, I would say that it's more of an application of BRMS. Let me explain. To enforce access level security, we have several touch points. For a web infrastructure, this may be a web agent or a reverse proxy that is fronting a set of web applications. An authenticated user requests a resource ( a url in this case). The proxy will interrogate that request and check its list of policies to see what is permissable. The policy may be a rule such as what I described above or it may be something more traditional like read,write access. My point is that the agent or reverse proxy becomes a natural place to enforce these rules. Also, by maintaining these rules in a centralized identity system, we lower the cost of administration. Another thing to consider is that a mid to large organization may have several of these agents or proxies. The centralized administration system needs to be able to define these agents, where they are located and maintain secure communication between the agent or proxy and the Identity server that maintains the policies. I have been working on a write up that explains this further as well as discusses the pros and cons of agent vs proxy based architecture. If you are interested, I can send it over. Regards Suneet
  8. So basically the access is enforced by executing a ruleset ? Yeah, that makes sense... Anyway, the flexibility of a rule-based approach makes sense in itself, but I had never thought about mixing it with access control... Also, as I told in other posts, I feel like we need more than "boolean security", even if the evaluated expression is powerful, just like what you propose through your rule-based system. Of course, large organizations want to make security an "aspect" that doesn't invade their code, but that ends where ACLs end (allow role "XYZ" to access resource "/foo/bar"). When you need real profiling, it becomes part of your *application logic* : it's not transversal any more... Anyway, don't hesitate to send some pointers about your approach, I'll certainly have a look at your approach ! Cheers Remi
  9. Hi Remi, I believe there are various use cases that need to be supported. In some cases a non-intrusive solution that can yield binary results is appropriate and in other cases you need to impose more fine grained options that may result in something more then a boolean outcome. A good system needs to address both scenarious. Your comments and Rickards are valuable and its great to see that we all agree that the problem is more complex then simply enforcing access to a URL. I agree with some standardizatio would be nice to enhance code portablility. I am need to take a look at XACML in more detail to see if it can facilitate this. This conversation has been more from an application centric view point from what I can tell. We also need to consider how security requirements would pertain to the other touch points in the enterprise as well as partners, system to system interaction. In an SOA model this comes up a bit more and we need to be able inject identity into SOA world. This is another problem that needs a bit of work. I did take a look at JFacets yesterday. Definitely interesting and can see how this would simplify development. I will send you some more information our approach in the next couple of weeks, once release version 3. Our solution set is broken out into 3 module - identity, access and audit. Feel free to contact me if you would like to discuss this further suneet at diamelle dot com. Regards Suneet
  10. Hi Suneet, Very interesting stuff ! I fully agree with your point. I don't think there's no silver bullet either : the solution is obviously depending on the problem, and ACLs can be an anwser to some "coarse grained" security issues... On the other hand, I feel like user profiling, even if more complex to grasp, can encompass different levels of granularity much easier. I mean, if your code is tailored to the user's role, why would you need to secure the way you access it ? Poeple run their code, that's all, no need to check if they're trying to run someone else's :-) In a typical JFacets-powered app, after you have logged in, the code that runs on the server has been written for your profile. When you click links and buttons (or send Ajax requests, or invoke a web service...), a controller on the server simply tries to retrieve some facets for your profile, and use them to handle the request. In that situation, securing URLs is almost meaningless ! The controller accepts all requests, and the work is done inside the facets... Authenticated users can only run the code you've assigned them : you don't need any other "aspect" in order to secure your application. Either the user has the facet and this code is used for handling the request, or he/she doesn't, and gets an exception (sort of "access denied") because no code was found for him/her. A completely different approach than "regular" access control techniques... Instead of allowing/denying to invoke some code, you just write that code directly for the users' profiles and let the framework retrieve it for you. If you follow this path, it leads to radically new perspectives. For example, it's really easy to track what users do when you write code for them... stuff that marketing fellows appreciate quite a lot :-) Cheers Remi
  11. The Access Manager does support groups and roles and the ability to define no trivial policies around these roles. In addition to the normal CRUD type of privileges that you may assign to a resource and role, you can also define policies around location and time. For example, you could define a policy that say that if a user profile indicates that a person is based in the US, but is accessing the system from the far east, then dont allow them in between a certain time window.
    One problem that I've found with access management in general is that it tends to be a bit simplistic due to the lack of integration standards. Most access management revolves around a binary "yes/no", i.e. should a user be allowed to use an application or not. What I'd really like to see is for security solutions to also pass along role assignments in case the user is allowed. For example, if a user is allowed to access an application that application should receive not only the username of the user but also any assigned roles that have been configured in the access manager. In WSRP support for these kinds of things is built-in, but I'm not sure how many policy tools support it. For regular web apps the security tool should be able to pass along role assignments using custom headers. I've just added this to our own portal engine for the case where a portal integrates another application through web clipping. The portal does all the tricky security and authorization checks, and passes on the roles of the current user as a custom header so that the underlying application only has to check that header for what the user is allowed to do. If it's a Java app we can provide the application with a servlet filter that implements isUserInRole() to check our custom header. This is the kind of stuff that access management tools should provide. But how many do it? My experience is that the main feature they provide is just a binary "can access/no access", which is pretty simplistic. On an intranet, for example, all users can access all apps, and the really important question is really *what* that user may do with an app, rather than *if* he/she can access it at all.
  12. Hi Rickard, You raise some interesting points and these are certainly some limitation of many of the solutions on the market. This is partially the result a lack of standards. If you are looking at coarsed grained authorization, which in the case of a web application, would be the ability to access a resource or not. So the binary action holds up. There are other situations where you need the detailed role based privileges. For this we offer two options. One is our API, which will solve the problem, but will also lock you into a vendor specific model. The second approach is through header injection, which is similar what you mention below. The reverse proxy in our case has the ability to inject custom information into the header. This enables so to solve a couple of problems. 1) Providing group/role/privledge information to the application 2) Enable SSO TYPE of behaviour by doing form fill. This is helpful when you have a 3rd party app that you cannot modify to ready your sso tokens/cookies/etc. A good access management system needs to handle both the course grained and fine grained authorization models. I agree that most done. I fact I only know of one other vendor that is doing this. Regards Suneet
  13. One is our API, which will solve the problem, but will also lock you into a vendor specific model.

    The second approach is through header injection, which is similar what you mention below.
    Good, then I was not alone in figuring that one out. It would probably be a good idea to standardize the name and format of such headers. It doesn't seem like rocket science.
    The reverse proxy in our case has the ability to inject custom information into the header. This enables so to solve a couple of problems.

    1) Providing group/role/privledge information to the application

    2) Enable SSO TYPE of behaviour by doing form fill. This is helpful when you have a 3rd party app that you cannot modify to ready your sso tokens/cookies/etc.

    A good access management system needs to handle both the course grained and fine grained authorization models. I agree that most done. I fact I only know of one other vendor that is doing this.
    Well, we do all of that too, but our product is not a reverse proxy but rather a portal integration engine, which is a bit different. We have a portlet that does web clipping (see portletbridge.org for a description of something similar to what we do), and which sends role headers to the underlying apps as outlined. That is pretty cool since it allows you to not only use the portal for security decisions, but also implement a more integrated look&feel of the apps since the web clipped HTML can be made to work with the CSS of the portal website. Reverse proxies usually can't do any such things. We are actually advocating that developers do their apps as regular webapps in Tomcat(/or similar) and then use the web clipping technique to get into the portal, as opposed to writing portlets that run in the portlet container. Works very well, and has several advantages from a production and development point of view. We have a couple of large government projects running right now that do their entire set of functionality using these techniques.
  14. ACLs vs User Profiling[ Go to top ]

    My experience is that the main feature they provide is just a binary "can access/no access", which is pretty simplistic. On an intranet, for example, all users can access all apps, and the really important question is really *what* that user may do with an app, rather than *if* he/she can access it at all.
    In my arms, brother :-) JFacets is an implementation of what you've just stated : "do something for somebody" instead of "allow/deny access to something for somebody" ! The idea is that instead of selecting what to do, you write some profiled code, specific to your users profiles, and let the framework inject that code where needed at run-time. I call this "user profiling" or "profile-based IoC", as it's much more than access control : here, you want to behave in a personalized fashion depending on who's behind the browser (e.g. show different screens to different users etc.). With JFacets, you write code explicitly for your profiles at design-time, and retrieve that code for the current user's profile at run-time. So there's no "allow/deny" policy : instead you "do something for somebody", by writing the appropriate facet (a POJO) and assign it to the appropriate profile. I've been designing several apps using this principle, and it's really awesome. Programming by intent to the max (you write your code for your end users and your objects) ! Check it out, I think you'll like the idea :-) Cheers Remi
  15. Yale Cas works wid most of the app servers and supports RDBMS, but doest
    provide support for authorization (Roles/Groups)
    Hi Sudhir, SSO is an authentication feature, which is usually "decoupled" from authorization stuff (know who you are vs. know what you can or can't do). You may want to have a look at Acegi : http://www.acegisecurity.org It provides a very good integration of both worlds (although I've never tried the CAS integration) and is pretty easy to use. Also, IMHO, "regular" authorization techniques are just painful and unefficient. Have you considered the JFacets approach ? http://jfacets.rvkb.com It proposes a different way to handle "profile-based" stuff that goes far beyond the regular "if (user.isInRole(ADMIN)) ..." way, which is basically what you do when using standard ACL packages... And it integrates fine with Acegi for the authentication, so I suppose it would be pretty easy to use CAS for SSO. HTH Remi
  16. Yes, I have already worked wid ACEGI. but the problem is tht it works only wid spring. im already using ACEGI for one of our project. but in our current project, its a jsp only application. it has been already developed so i cant go for ACEGI. I know ACEGI provides support for Authorization on top of Yale CAS using CasAuthoritiesPopulator sudhir nimavat http://www.jyog.com
  17. Hi remi Yes, I have already worked wid ACEGI. but the problem is tht it works only wid spring. im already using ACEGI for one of our project. but in our current project, its a jsp only application. it has been already developed so i cant go for ACEGI. I know ACEGI provides support for Authorization on top of Yale CAS using CasAuthoritiesPopulator sudhir nimavat http://www.jyog.com
  18. Acegi Without Spring[ Go to top ]

    Hi Sudhir,
    the problem is tht it works only wid spring. [...] but in our current project, its a jsp only application.
    Sure, you'd have to ship the Spring jars, but you can secure access to URLs with Acegi, wherever they point to... so I think you can use it with JSPs only ! I'm using Acegi in a Stripes/JSP project, for securing some Action URLs. We don't use Spring MVC there, and still Acegi works fine. And btw I have no participation in Acegi, it's just that I've always been very happy with it... ;-P Cheers Remi
  19. Re: Atlassian Crowd 1.0 for Web App SSO[ Go to top ]

    Before few days.. i was searching for an opensource SSO solution,
    I have tried many
    (JOSSO,JAAS wid Kerberos, spnego, OpenSSO, Yale CAS)
    but most of them have some limitations..
    As I need to support User profiles stored in RDBMS (MySql)
    While most of them requirs User profiles to be stored in
    Active Directory or some other directory servers.

    JOSSO do the work for me but it doesnt support Apache Geronio.

    Yale Cas works wid most of the app servers and supports RDBMS, but doest
    provide support for authorization (Roles/Groups)


    What abt Crowd. do it fulfills all my needs?

    Sudhir Nimavat.
    Http://www.jyog.com
    This is one of the areas that Crowd really works well. Here is our current documentation on accomplishing something like this: http://confluence.atlassian.com/display/CROWD/2.2.3+Configuring+a+Custom+Directory+Connector Our answer to this type of problem is that you implement our RemoteDirectory interface and let Crowd know your implementation through our administration console. Justen Stepka http://www.jstepka.name/blog/
  20. Atlassian Software Systems today announced the general availability of Crowd 1.0, a single sign-on application for helping manage authentication and authorisation for multiple web-based applications.
    Interesting to see that you are getting into this space. It is a very difficult one, but the current available products have not impressed me one bit so it's definitely possible to do something interesting with it. Especially when you get into portal integration many products just don't get it. But speaking of SSO, one of the apps we have had trouble with internally is actually Jira, since it doesn't use LDAP as the user store. Is it now(/soon?) possible to have all users in an LDAP instead of having to duplicate our directory in Jira? That would be very very nice. (and my personal opinion is that custom user databases in general should die. Please please please use LDAP instead)
  21. Atlassian Software Systems today announced the general availability of Crowd 1.0, a single sign-on application for helping manage authentication and authorisation for multiple web-based applications.

    Interesting to see that you are getting into this space. It is a very difficult one, but the current available products have not impressed me one bit so it's definitely possible to do something interesting with it. Especially when you get into portal integration many products just don't get it.

    But speaking of SSO, one of the apps we have had trouble with internally is actually Jira, since it doesn't use LDAP as the user store. Is it now(/soon?) possible to have all users in an LDAP instead of having to duplicate our directory in Jira? That would be very very nice.

    (and my personal opinion is that custom user databases in general should die. Please please please use LDAP instead)
    Exactly! With Crowd, you can now have all of your users in Crowd (LDAP/Active Directory/DB), and they will be available to JIRA. Group information and the relationships users have are also part of the dataset given to JIRA. Justen Stepka http://www.jstepka.name/blog/
  22. How much coding does a developer have to do to switch between user repositories?
  23. Hi Neal, It really depends on the integration path that the developer uses to start with. In our approach, the coding effort to swith repositories is 0. The backend is transparent to the rest of the system. We define this in the configuration and the policy definitions. Regards Suneet