OSIAM as Identity Manager for a Services Oriented Architecture

[Ariel Kogan]

Hi guys,

I'm looking for an Identity Management solution for a system we'd like to start splitting into smaller pieces, something towards an SOA or microservices, those are the current buzzwords in the industry. I've run into OSIAM and I think it could be a very good fit. I'd really appreciate if you could share your opinion about the following questions I have,

• Do you agree that OSIAM is a good fit as an Identity Manager for a services oriented architecture?
• Is there a way to skip the confirm "I'm ok to grant this application permissions" so users will just log in into our system as usual and that's it?
• Can the login page be customised?
• In case services are going to be spread around different datacentres, could OSIAM provide replication of its services or should all services point to the same OSIAM instance in order to authenticate?

Thanks for the time,

Ariel

[Sebastian Mancke]

Hi Ariel,

thank's for you interest in OSIAM.
See my comments inline.

Am 01.05.2015 um 12:20 schrieb Ariel Kogan:
> Hi guys,
>
> I'm looking for an Identity Management solution for a system we'd like to
> start splitting into smaller pieces, something towards an SOA or
> microservices, those are the current buzzwords in the industry. I've run
> into OSIAM and I think it could be a very good fit. I'd really appreciate
> if you could share your opinion about the following questions I have,
>

> - Do you agree that OSIAM is a good fit as an Identity Manager for a
> services oriented architecture?
Yes, this is exactly the way we use it our self and why we started
OSIAM. We like the idea of small applications/services working together,
where every service only does what it is designed for. In such a
scenario OSIAM can handle user management and authentication.


> - Is there a way to skip the confirm "I'm ok to grant this application

> permissions" so users will just log in into our system as usual and that's
> it?

Yes, when adding an OAuth2 Client (e.g. by making an entry in the
database table osiam_client), there is the property
implicit_approval=TRUE/FALE.

> - Can the login page be customised?
Take a look at: /etc/osiam/auth-server/templates/web/*.html

> - In case services are going to be spread around different datacentres,

> could OSIAM provide replication of its services or should all services
> point to the same OSIAM instance in order to authenticate?

The short answer is: Currently OSIAM does not have support for
replication. So you should go with one instance.
Depending on your scenario it could make sense to choose a more complex
configuration nevertheless. This could be_ database replication with
postgres or mysql and separation of the OSIAM auth-server from
osiam-resource-server.

Regards,
Sebastian

--
Sebastian Mancke
head of technology
tarent solutions GmbH

Mobil +49 171 7673249
Telefon +49 228 54881-216
s.ma...@tarent.de

Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-0 • Fax: +49 228 54881-314
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander
Steeg

[Ariel Kogan]

Thanks a lot Sebastian, this is very very useful. Hope to start implementing OSIAM soon. Thanks for making this solution available.

[Thomas Krille]

Hi Ariel,

we're glad you're thinking about using OSIAM. Some thoughts on your questions follow inline:

• Can the login page be customised?

Yes, it can, see https://github.com/osiam/server/blob/master/docs/detailed_reference_installation.md#configuring-login-with-authorization-code-grant (beware: the documentation will move during the next days/weeks)

• In case services are going to be spread around different datacentres, could OSIAM provide replication of its services or should all services point to the same OSIAM instance in order to authenticate?

Actually, the two central services (auth- and resource-server) are stateless and can be deployed and scaled individually. There's just one little part that's not stateless: the web sessions on the auth-server. But I think you can configure Tomcat in a way that enables replicated sessions over multiple instances. All the state is stored in a SQL database that can be replicated with the usual means. Currently only PostgreSQL and MySQL are officially supported, but both are capable of multi datacenter replication. If you enable session replication somehow, it should not matter to which auth-server or resource-server your clients connect. I think the same applies to the addon-self-administration, our account self-service app, too.

Have fun with your first steps using OSIAM and feel free to ask us for help. If you find a bug or you're missing a feature, feel free to create an issue here: https://github.com/osiam/osiam/issues. We're always happy about pull requests, too :)

[Thomas Krille]

Oops, I forgot something. At this time all the OAuth access tokens are stored in-memory in the auth-server. So scaling the auth-server is not possible at the moment. But if you have a need for this, we will happily implement it for you. This is something that OSIAM needs anyway :)